three lists. three numbers. none of them real

Ask three different people in a 200-person company how many SaaS applications the company uses.

The head of IT will say 47. That’s the number in the procurement system, plus a handful of things IT bought directly, minus the ones that got sunset last quarter but are still on the spreadsheet because nobody updated it.

The security lead will say 31. That’s the number of applications integrated with SSO. It’s the only number they can defend with evidence, so they use it when a board member asks.

The CFO, if you give her a week to pull the data, will come back with 218. That’s the number of unique merchants across twelve months of expense reports that match any SaaS taxonomy. About 140 of them are clearly SaaS. The rest are probably SaaS. She doesn’t know, because nobody asked her to track it, and her job is to pay invoices, not to maintain an application inventory.

Three lists. Three numbers. None of them is the real number.

This is the problem that sits underneath every other identity problem in your company. You cannot offboard someone from a system you don’t know exists. You cannot run an access review on an application that never appeared on any list. You cannot write a data protection policy for data that lives somewhere you never mapped. Every control you buy, every process you write, every audit you pass, all of it is downstream of the question which applications are we actually using?. And the industry has a surprisingly bad answer.

This essay is about the gap between the application list your company thinks it has and the application list your company actually has. It’s about why every number is wrong. It’s about where the real inventory lives, and why nobody in security ever looks there.

the IT list is the procurement list

The list IT maintains is, in most companies, a byproduct of procurement. When someone fills out a software request form, the application gets logged. When a contract is signed, it goes into the vendor management system. When renewals come up, they get tracked in a spreadsheet.

The list is real. Its accuracy is another matter.

It’s not accurate because procurement is not the trigger for most SaaS adoption in a modern company. A product manager signs up for a free tier of a new tool. The trial works, the team likes it, they upgrade on a team leader’s credit card. Six weeks later, someone in finance notices a recurring charge and asks what it is. By then, twenty people are using it. Procurement gets looped in at the renewal, months after deployment, after the tool is already embedded in how the team works.

The gap is often stark: the procurement-sourced list covers only part of the SaaS actually in use. The rest entered the company through channels that procurement never touched.

The procurement team isn’t failing here. The structure of how SaaS is sold guarantees this outcome. Every modern B2B SaaS tool is designed to land through product-led growth, free tier, self-serve signup, team expansion, which means the tool is already deployed before any central function gets involved. The vendor’s whole business model depends on bypassing procurement. The vendor wins when the tool lands without IT noticing.

If you’re using the IT-maintained list as your source of truth, you are using the output of a process that was structurally designed to be bypassed.

SSO shows you only what agreed to be seen

The security list, the one the CASB or SSO shows, is a better list in some ways and worse in others.

It’s better because everything on it is, at least, real. If an application is federated with your identity provider, you know people are actively signing in to it. The usage is verifiable.

It’s worse because the only way an application lands on this list is by being integrated with SSO, and SSO integration requires a deliberate act by either IT or the vendor. Both parties have reasons not to do it.

The vendor has reasons not to, especially at the small and mid-market end. SAML and SCIM integrations are often gated behind enterprise tiers. A vendor selling a $15/user/month product is not going to offer free SSO to a 30-person team that signed up via credit card, because the SSO-less experience is exactly what nudges that team toward the $40/user/month enterprise tier twelve months later. SSO tax is a real thing. It means that the cheaper the application, and the earlier its adoption lifecycle, the less likely it is to be on your SSO.

IT has reasons not to, too. Every SSO integration is work. Configuration, testing, documentation, ongoing support when users hit errors. For an application with twelve users that was bought six weeks ago, SSO integration sits below more important work forever. The application stays on local auth, a password, a team-shared login, a Google OAuth, and never appears on the security team’s list.

The net effect: your SSO inventory is heavily biased toward old, expensive, enterprise-tier applications. Everything newer, cheaper, and more agile, which is to say, everything the company is probably actually using, sits outside it.

When a CISO says “we have visibility into our SaaS footprint,” and means the CASB list, they mean visibility into the enterprise-tier subset. Which is a meaningful subset. Which is also, usually, a minority of the total.

four ways to count your SaaS, and what each one sees

• finance (N1)everything paid for: the largest list
• single sign-on (N2)only what was connected: the smallest
• procurement (N3)only what went through approval
• OAuth grants (N4)apps people connected themselves

the CFO has the real list

The highest-fidelity source of SaaS inventory data in your company is, almost without exception, the finance system. Specifically: the expense report line items, the corporate card transaction feed, and the vendor master.

Every SaaS tool, by definition, is paid for. Every payment generates a financial record. If you can extract twelve months of recurring merchant charges from the finance system and filter for anything that looks like a SaaS subscription, you have a list that is more complete than anything IT or security can produce.

This list has problems of its own. It includes applications that the company has stopped using but hasn’t canceled. It misses applications that are genuinely free (some are). It misattributes charges when a vendor changes billing names. It captures the same vendor under multiple aliases if different teams signed up through different channels.

Those problems are real. They are also smaller than the problems of the other two lists.

Expect the finance-derived SaaS count to be much larger than the IT-reported one. The gap is always in one direction. Finance sees everything that costs money. IT sees everything that went through the approval process that most things don’t go through.

The reason finance data doesn’t become the authoritative SaaS inventory is organizational. Nobody has asked the CFO for this data in the framing of “give us your SaaS inventory.” Finance thinks their job is to pay invoices, track spend, and close the books. When security and IT ask for application inventory data, they ask each other, not finance. So the best dataset in the company sits unused for the exact purpose it’s most useful for.

The intervention is mechanical. Quarterly export. A one-page taxonomy mapping merchant names to application categories. A half-day of reconciliation work to line up merchant name variants. After three iterations, you have a living, finance-sourced SaaS inventory that updates itself every time someone expenses something.

The work is mechanical. The failure is that nobody thinks to do it.

the OAuth gray market

There is a fourth inventory problem, and it sits outside all three lists above, because it doesn’t require either procurement or payment.

A significant fraction of the SaaS tools employees use in a modern company are integrated via OAuth grants, the “sign in with Google” or “sign in with Microsoft” flow. An employee grants permissions to a third-party application to access their Google Drive, or their Gmail, or their Microsoft Graph. The application now has an access token. It can read documents, read email, pull calendar data, depending on the scopes granted.

From the employee’s perspective, nothing happened. They clicked through a consent screen. The tool now works. There is no payment, no procurement record, no SSO integration. From IT’s perspective, nothing happened either, because the employee authenticated with their existing Google or Microsoft identity, nothing unusual showed up in the identity provider logs beyond a normal login.

From a security perspective, a lot happened. An external application now has a standing grant to read corporate data. The grant persists until explicitly revoked. The application can be from anyone, a legitimate vendor, a defunct startup whose code was sold to someone else, a thin wrapper around a data-exfiltration pipeline. The scopes granted are usually broader than the application actually needs, because vendors request the maximum useful scope set and employees click accept without reading.

Companies can pull OAuth grants from Google Workspace or Microsoft admin consoles. Almost none do, systematically. The numbers are usually surprising. A 200-person company often has 300 to 500 third-party OAuth applications with active grants across their employees’ accounts. Most of them are benign. Some are abandoned. A few are things nobody at the company can explain.

This is a fourth list, invisible to procurement, invisible to SSO, invisible to finance. It shows up only if you go look at the OAuth admin interface, which nobody opens unless they have a specific reason to.

The OAuth gray market is the purest form of the discovery problem: applications with real data access, bypassing every control the company has, requiring no payment and no approval, and visible only if someone knows to look.

shadow IT is the market working

The conventional framing of shadow IT treats it as a discipline problem. People are going around the process. The solution is better enforcement, better policy, better training, a stronger CASB.

This framing is wrong, and it’s been wrong for about a decade.

Shadow IT exists because centralized procurement is slower than team-level need. A product manager who needs a new research tool can spend three weeks going through the procurement process, or they can put $40 on a credit card and have it running in twenty minutes. The product manager is making a rational choice. The company’s procurement process is not priced to compete with a credit card and a Tuesday afternoon.

The tools that show up in shadow IT are also, often, the ones that actually work. Centralized procurement tends to select for enterprise-tier, heavyweight solutions with long sales cycles and expensive contracts. Team-level adoption selects for fast, cheap, focused tools that solve one problem well. The shadow IT list is a revealed-preference list of the tools that have actually earned their place in the workflow.

Which means the discovery problem has a cultural layer on top of the technical layer. A security team that positions itself as the enforcement arm against shadow IT gets treated as an adversary, and employees get better at hiding what they’re using. A security team that positions itself as an ally, “tell us what you’re using, we’ll help you use it safely”, gets cooperation and real inventory data.

This is mostly a distribution problem. Tools that reach security through cooperation stay visible. Tools that are hidden from security stay hidden. The choice of stance determines which tools you see.

discovery is the precondition

Everything downstream of identity security depends on knowing your application footprint. Offboarding requires it. Access reviews require it. Data protection requires it. SaaS security posture management is a category that exists because nobody knows their footprint. AI data governance requires it squared, because every AI tool needs to understand where data lives before it can decide what the AI can see.

The industry has built an enormous amount of software to solve downstream problems while leaving the upstream problem, what’s even in our environment?, mostly unsolved. The result is the pattern you see in every mature security program: the downstream controls get better, the upstream gap stays the same, and the controls produce reports about the 30% of the environment they can see while the 70% they can’t see operates unobserved.

The way out is mechanical. Pull the finance data. Cross-reference the SSO data. Export the OAuth grants from Google and Microsoft. Reconcile into one list. Investigate anything that appears in one source but not another. Do this quarterly. After a year, you have the real inventory.

A company can spend a large budget on a SaaS security posture management tool, deploy it, and then discover it covers only part of the footprint, because the connectors only work on the applications the company already knew about. The upstream discovery problem cannot be solved by a purchase, it’s an organizational practice, and running it well is worth more than most of the tools it enables.

the reconciliation exercise

Here’s the specific thing to do after reading this, if you run security or IT at a mid-market company.

Ask finance for a CSV of all recurring vendor charges from the last twelve months. Any recurring charge, credit card, ACH, invoice. Tag every line that looks like a SaaS subscription. Count the distinct vendors. Call this N₁.

Pull your SSO application list. Count the applications. Call this N₂.

Pull your procurement-approved application list. Count the applications. Call this N₃.

Export the OAuth grants from Google Workspace or Microsoft 365 admin. Count the distinct applications with active grants across your user base. Call this N₄.

N₁ will be the largest. N₂ will be the smallest. N₃ and N₄ will surprise you. The intersection of all four will be smaller than any single one of them.

The gap between N₁ and the union of N₂–N₄ is your discovery gap. That gap is the invisible portion of your SaaS footprint, the applications that are paid for but not federated, not approved, and not cataloged. It is where your next breach lives.

Run this exercise once. You will not forget the number.