The buyer's guide to SaaS governance and SaaS security tooling

where buyers go wrong

"SaaS governance" means three different things depending on who is saying it. To a finance or operations lead it means cost: too many licenses, overlapping tools, renewals that auto-charge before anyone reviews them. To a security lead it means posture: misconfigured apps, over-shared files, risky third-party integrations reaching into company data. To a compliance owner it means evidence: who has access to what, proof that access gets reviewed, an audit trail that holds up. These are three separate problems. They overlap, but no single tool covers all three well, and most honest tools only claim one. Name the problem in one sentence first. If you cannot say whether you are solving for cost, security, or compliance, you are not ready to evaluate anything.

The second error cuts across every size of company: teams sign contracts before they have a real number for the apps they run. A ten-person startup assumes it has a dozen tools and has sixty; a four-hundred-person company assumes it has a hundred and has four hundred. The miss is structural, because the apps that escape your mental model are exactly the ones nobody put in a register: the free tools, the personal-account sign-ins, the single app one team expensed and forgot. In one study, 49% of frequent Microsoft 365 users believed they had fewer than 10 connected applications, while the real average was more than 1,000 (AppOmni, 2024). If your own estimate is off by an order of magnitude, every coverage claim a vendor makes is something you have to take on faith.

before you evaluate: discover what you run

You can start this week, with tools you already pay for, before you talk to a single vendor. Begin at your identity provider. Whether you run Microsoft Entra, Okta, or Google Workspace, your IdP holds two views worth pulling: the list of apps your users sign into through single sign-on, and the list of OAuth grants, every third-party app a user has connected to your core platforms by clicking allow. That OAuth list is usually the most under-examined surface in the building, and it costs nothing to look at. This first look gives you a floor for your app count and the shape of your exposure. Walk into a demo already knowing you have, say, 180 apps and 240 OAuth grants, and you can ask a vendor to find them and check the answer against your list. Walk in blind and you are taking their word for everything.

Once you have a rough count and a named problem, locate your tier. Lean and small (up to roughly 50 people) means few apps, no dedicated IT security person, and work that is mostly discovery and a handful of cleanups. Growing mid-market (roughly 50 to 500) means app count climbing faster than headcount and the first real compliance pressure, where the category decision matters most because the wrong one wastes both money and scarce time. Larger and multi-entity (roughly 500 to 2,000) means multiple business units, possibly multiple IdPs, and decentralized buying, where coverage and consolidation become the hard part. Enterprise and regulated means a security function exists and the question is which platform and how deep.

the category in depth

Four categories show up when you shop this space. They sound similar and they are not. Each solves a different problem and discovers differently, and the overlap between them is where buyers get confused.

A SaaS management platform (SMP) discovers the apps in use, tracks licenses and spend, and manages renewals. The core job is cost and visibility: which tools you pay for, who actually logs in, where you are double-paying, what renews next month. Discovery here often leans on expense and finance data. The problem it solves is money and tool sprawl; around 48% of enterprise apps are unmanaged (Productiv, 2024), and an SMP is aimed at pulling those back onto a budget. Reach for it when the pain is spend; skip it when the question is whether your apps are configured safely.

An SSPM (SaaS security posture management) looks inside your major SaaS apps and checks how they are set up: misconfigurations, weak default settings, files shared too broadly, dormant admin accounts, and risky OAuth and connected-app grants. It solves security posture inside the apps that hold your sensitive data. It tends to go deep on a supported list rather than wide across everything, so it is the wrong tool if your problem is finding the long tail of unknown apps or controlling spend. Depth on ten apps does not help if your eleventh, unsupported app is the one holding the data.

A CASB (cloud access security broker) sits in the path of traffic to cloud apps, inspects it inline, and enforces data-loss controls. It can block an upload, flag a download, and police data movement between sanctioned and unsanctioned apps. It came from a time when most access flowed through a corporate network you controlled, so the model fits distributed, browser-first work less cleanly than it once did. Reach for it when inline data-loss control is the specific job, and do not expect it to do configuration posture or spend.

Identity-led discovery uses your own IdP and its OAuth-grant list to see connected apps and single-sign-on apps. It is the cheapest first look and the one most teams skip. It solves connected-app exposure and a baseline app count, fast and free, with tools you already own, and it is the foundation under everything else. Always do it first, regardless of tier. It will not catch apps that live entirely outside single sign-on, so it is a floor and not a ceiling. The overlap confuses people because an SMP and an SSPM both "discover apps" but discover different apps for different reasons, a CASB and an SSPM both touch security but one watches traffic and the other inspects configuration, and identity-led discovery underlies all of them and replaces none. When a vendor implies theirs covers cost, security, and compliance at once, that is your signal to ask which of the three problems it actually solves well.

what is right for your size and situation

Match the category to your tier before you match a product to your category. A lean, small company's typical problem is an unknown app count and a few risky grants; the first move is an IdP and OAuth review you run yourself, the likely category is identity-led discovery then a light point tool if needed, and a platform is almost always overkill. A growing mid-market company faces sprawl plus first compliance pressure; baseline, then name the one problem that hurts most, and buy one point tool matched to it (SMP or SSPM). A larger, multi-entity organization needs coverage across units and consolidation; map every IdP and buying center, then choose a platform or two point tools that integrate, watching for paying for breadth you will not staff. An enterprise and regulated organization needs continuous posture and evidence; decide depth and residency requirements first.

Some special cases override the tier. Heavy SaaS sprawl, where app count is far ahead of headcount, puts discovery and consolidation before anything else, because you cannot secure or budget for what you have not found. A financial entity in the EU carries ICT third-party risk obligations under DORA regardless of size, which pushes you toward tooling and process that produce evidence of third-party oversight. Regulated data (health, financial, or other) makes posture depth on the specific apps that hold it outweigh breadth across the rest. Decentralized buying, where departments buy their own tools without IT in the loop, means discovery has to reach past the IdP and past the corporate card, and a buying policy and review cadence help as much as a tool.

sourcing models

How you acquire the capability matters as much as which category you pick. IdP-led discovery you run yourself fits when the goal is to see your current state and you are not ready to commit budget, or when you are small enough that a recurring manual pass is realistic; it does not scale into continuous monitoring. A point tool (SMP or SSPM) fits when you have named one problem clearly and a focused product will close it without a platform's cost; most growing mid-market companies belong here. A platform fits larger and multi-entity organizations that would otherwise stitch together several tools, with the risk of paying for breadth you never staff. A managed SaaS security service via an MSSP or VAR fits when you want the outcome without building internal expertise you will rarely use again; the risk to avoid is a partner whose advice points only at the one product they resell.

decision criteria in depth

Once you know your problem, your tier, and your baseline, the comparison comes down to a short list of things that predict whether a tool will work for you. Score each candidate against the same rows. How it discovers is the criterion that matters most and the one demos gloss over: IdP and OAuth sees connected and single-sign-on apps, network or proxy sees traffic but struggles with remote and browser-first work, expense data sees anything that hit a card and is blind to free tools, and browser extension sees what people actually open including free and personal-account tools. Agent versus agentless trades coverage for operating load; agentless connects by API, deploys in hours, and stays light, and is usually the sane starting point for smaller teams. Find versus fix separates a dashboard that lists 240 OAuth grants from a tool that can revoke a grant, narrow a permission, or remove an account from inside the tool. Data residency and EU matters for a European company: ask where data is processed and hosted, what the sub-processor list looks like, and whether the arrangement fits your GDPR posture. Coverage of your real apps, checked line by line against supported integrations, decides whether the tool sees your five most sensitive apps. Pricing model, admin overhead, time to value, and vendor viability round out the table.

how it is priced and the true total cost

Pricing follows a few models, and the sticker rarely matches the bill. Per-app pricing penalizes the discovery you wanted; per-user scales with headcount, contractors, and service accounts; percentage of SaaS spend rises even as the tool saves you money; per-connected-SaaS charges for each major app you connect for deep monitoring; and platform tiers gate features so one capability pushes you up a tier. The license is the visible part; the rest hides in four places. Integrations take time and some connectors cost extra or need a higher tier. Depth of monitoring may discover on a base tier but charge more to inspect configuration or watch continuously. Services (onboarding, tuning, support) are often a separate and sometimes required line. Admin time, the hours your team spends running the tool, is real cost that never appears on an invoice. A cheap tool that eats a day a week is not cheap, so total the visible price, the services, and the admin load before you compare two quotes.

how to run the evaluation

A disciplined process beats a long shortlist. Shortlist from your named problem and your tier, not from a roundup of every vendor, and cut anything that does not solve the one problem you named. Send the same RFP questions to each candidate so the answers compare: which discovery methods do you use and what does each miss, here is my list of apps so which do you support and at what depth, will you find my OAuth grants and connected apps including the ones outside single sign-on, do you only report findings or can you remediate them from inside the tool, where is my data stored and processed and who are your sub-processors, what does this look like to run with no dedicated administrator, and what is the all-in cost at my user count and app count after the first year. A proof of concept is where you learn the truth: point the tool at your real estate and check what it discovers against the known list you built from your IdP and OAuth review, with success criteria set before you start. Reference checks are best with a customer at your own tier, asking what broke, what onboarding really took, and whether find-versus-fix held up. Then decide: score every candidate against the same criteria table, weight the rows that matter for your tier, and pick the one with better time to value and lower admin load when two are close.

traps and red flags

A few gaps are structural and only show up if you go looking. Discovery-method blind spots mean a demo runs against a curated environment where everything resolves cleanly while yours will not; anything outside single sign-on tends to stay invisible to IdP-led tools, so the AI assistant signed into with a personal account, the free design tool a team adopted, and the marketing app someone expensed once can sit entirely outside the picture while the dashboard looks full. A full-looking dashboard is not full coverage; ask the vendor to show you an app they do not support so you see the edge of their map. The gap between a dashboard and a fix is real, because it is easy to list problems and hard to safely revoke a grant or narrow a permission without breaking something a team depends on. The services trap catches tools that are cheap to license and expensive to run because every real outcome needs a paid services engagement. And license-reclaim claims from an SMP promise savings you still have to realize: the tool finds the unused licenses, but someone on your side still has to cancel them and absorb the change-management, so treat projected savings as a ceiling that needs work to reach.

where this maps to regulation

Two EU frameworks turn SaaS visibility from good hygiene into an obligation. NIS2 pushes supply-chain security up the agenda for in-scope organizations: your SaaS providers are part of your supply chain, and you are expected to manage the risk they carry, which you cannot do for providers you have not catalogued. DORA sets explicit ICT third-party risk requirements for financial entities: you need to know which providers are critical, what access they hold, and what happens if one fails, with the access dimension (who can reach what, and whether it is reviewed) mattering as much as the inventory. In both cases the regulatory ask starts from the same place as the practical one: you have to see what you run before you can govern it.

a sequenced path

The sequence beats the shopping, in three moves. Crawl: name the problem in one sentence, pull your IdP app list and your OAuth grants, and build a baseline count and a ranked list of risky grants in a spreadsheet; this costs nothing but time and tells you whether you even have the problem you assumed, and many teams fix the worst grants here before spending a euro. Walk: with a baseline in hand, decide whether the manual pass is enough or whether the problem is ongoing, and if it recurs, shortlist tools in the one category that matches your named problem, run a proof of concept against your real estate, and buy the one that matches your hand-built list. Run: once a tool is in place, set a cadence of a regular access and grant review, a renewal calendar, and an owner for each critical app. Done in that order, you spend on a tool that fits, or you find you did not need one yet. Both beat buying blind.