What SaaS Management Actually Is

Organisations buy a SaaS management platform expecting one thing and discover they had three problems. Separating them at the start determines whether the programme produces anything.

The three problems

Visibility. What applications does the organisation actually use, who uses them, and who owns each one. This is a discovery and reconciliation problem, and it is where every programme has to start.

Spend. What are we paying, for how many seats, on what contract terms, renewing when. This is a finance and procurement problem.

Governance. Who can access what, what data sits where, what happens when someone leaves, and which applications have been granted access to your other applications. This is a security and compliance problem.

They share an inventory and almost nothing else. The people who care about each are different, the work is different, and a platform sold as solving all three usually solves the second and reports on the first.

Why the inventory is hard

Nobody bought most of it centrally. A team signs up with a corporate card, or a free tier, or a personal account. It becomes load-bearing before anyone in IT hears about it.

There is no single source that sees everything. Identity provider sees applications with single sign-on. Expense data sees what was paid for. Endpoint agents see what is installed. Each misses a large share.

Applications change names, merge and get acquired. The reconciliation problem is worse than it looks.

Free tiers are invisible to finance and frequently hold real company data.

What the work actually consists of

Discovery, from several sources, reconciled.

An application register — the equivalent of a hardware asset register, and it is the artefact everything else references.

An owner per application. Not IT: a business owner accountable for whether it is still needed.

Licence and contract data attached to each.

A renewal calendar.

A joiner-mover-leaver process that actually reaches SaaS applications, which most do not.

A review cycle that removes what is no longer used.

Software helps with all of it and creates none of it, which is the same thing this material says about every tooling question.

The numbers that motivate it

Two findings recur across organisations that measure for the first time.

Applications in use exceed what IT knew about, frequently by a large multiple. An organisation confident it uses forty applications finds two hundred.

A substantial share of paid seats are unused. Assigned to people who left, or to people who logged in twice a year ago. Twenty to thirty percent is a common first measurement.

The second one funds the programme. The first one is why the security function should care.

What this material covers

Discovery and how to reconcile sources. Licence and spend work, including renewals, which is where the money is. Hardware asset management, because the same register discipline applies and the two are usually run by the same people. Access and offboarding. The security and compliance questions. And the tooling decision, last.

The framing that keeps it useful

SaaS management is inventory management applied to things nobody delivered in a box.

The discipline is old — asset registers, ownership, lifecycle, review — and the difficulty is entirely that the assets arrive without a procurement process, live somewhere you do not control, and can be created by anyone with a card and five minutes.

The first week

Five things that establish where an organisation actually stands, before any decision about tooling.

Export the application list from your identity provider. Ten minutes, and it is the cleanest data you have.

Pull twelve months of card and invoice spend filtered to anything recurring. An hour with finance.

Export OAuth grants from your email and file platform. Twenty minutes, and it is usually the most surprising output.

Count the distinct applications across all three after removing obvious duplicates.

Compare that number to what you would have guessed. The gap is the size of the problem and it is the only argument the programme needs.

None of this requires a purchase, a policy or a meeting, and it produces a defensible number by Friday.

Who this belongs to

The programme fails when it has no home, and the three plausible homes each distort it differently.

IT treats it as an inventory and integration problem, and under-weights the spend.

Finance treats it as a cost exercise, and under-weights the governance.

Security treats it as an exposure problem, and struggles to get owners to engage.

The workable arrangement is one owner with a standing relationship to the other two: a monthly figure to finance, a quarterly exposure report to security, and the register held wherever it will actually be maintained.

What does not work is a shared responsibility with no named person, which is how most first attempts are structured and why most first attempts stall after the discovery phase.