Subscribe to the Non-Human & AI Identity Journal

What is the most reliable way to spot SaaS spend waste in a large organisation?

Look for gaps between purchased licences, active users, and feature adoption, then compare those figures across departments. High-spend teams with low engagement, duplicate tools with overlapping functions, and apps with no recent usage are the clearest signals that spend is leaking through poor governance.

Why This Matters for Security Teams

The most reliable signal of SaaS spend waste is not the invoice total alone, but the mismatch between what was bought and what is actually used. In large organisations, that gap usually shows up as dormant licences, overlapping tools purchased by different departments, and premium tiers that were approved for a project but never normalised back down. For security and governance teams, this matters because underused SaaS often hides access sprawl, weak ownership, and shadow procurement.

That same pattern is visible in identity and access failures: NHIMG notes that only 5.7% of organisations have full visibility into service accounts, and visibility gaps almost always delay clean-up. The same lesson applies to SaaS estate management. When teams cannot see who is using an app, which features are active, and whether the business still depends on it, they cannot distinguish strategic spend from waste. The result is budget leakage that persists until renewal, audit, or breach response forces a review. The NIST Cybersecurity Framework 2.0 reinforces that asset visibility and governance are foundational, not optional. In practice, many security teams encounter SaaS waste only after renewals have already passed and unused licences have been paid for another year.

How It Works in Practice

The most dependable method is to compare three views of the same estate: purchased licences, active users, and feature adoption. A finance report can show seat counts, but it will not reveal whether people are logging in or whether they are using the capabilities that justify the spend. Security and operations teams should therefore pair procurement data with application telemetry, identity logs, and department-level ownership. That creates a clearer picture of where spend is genuinely supporting work and where it is simply sitting idle.

A practical review usually starts with:

  • Licence utilisation by app, team, and region
  • 30, 60, and 90-day activity for named users
  • Feature adoption for premium functions tied to higher tiers
  • Duplicate tools with overlapping workflows, especially across business units
  • Orphaned seats tied to former staff, contractors, or projects

This approach becomes stronger when paired with governance patterns used for other high-risk access pathways. The same discipline that prevents wasted or overprivileged access in the Ultimate Guide to NHIs — What are Non-Human Identities applies here: ownership, lifecycle, and revocation matter more than static purchase records. SaaS waste often tracks the same root causes as credential sprawl, which is why breach case studies such as the Snowflake breach and the Salesloft OAuth token breach are useful reminders that unused or poorly governed access tends to accumulate silently before it becomes expensive. When departments self-provision apps without a common review standard, this guidance breaks down because usage data is fragmented across admin consoles, procurement systems, and disconnected business owners.

Common Variations and Edge Cases

Tighter SaaS governance often increases administrative overhead, so organisations must balance cost recovery against the friction of constant licence policing. That tradeoff is especially real in large enterprises with M&A activity, regulated workflows, or decentralised buying authority. Current guidance suggests that the best results come from tiered review rules rather than treating every app the same.

Some edge cases need a different lens. A low-use app may still be justified if it is tied to compliance, incident response, or seasonal business cycles. Likewise, a department may appear inefficient because it owns shared enterprise tools that other teams consume indirectly. Best practice is evolving here: there is no universal standard for what counts as acceptable adoption across every SaaS category. The safest approach is to require an owner to explain the business function, renewal trigger, and expected adoption threshold for each high-cost application.

For deeper governance, compare your internal review process against NIST CSF 2.0 asset oversight principles and use NHIMG breach research to prioritise the tools most likely to hide control gaps, including the BeyondTrust API key breach and the Dropbox Sign breach. Where feature telemetry is unavailable, teams should treat the app as partially unmeasured rather than fully optimised.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.OV-01 Governance oversight relies on knowing whether SaaS assets are actually used.
NIST CSF 2.0 ID.AM-01 Asset management is the base control for identifying unused or duplicate SaaS.
NIST CSF 2.0 ID.AM-02 Understanding dependencies helps distinguish critical apps from wasted spend.

Establish recurring SaaS inventory, ownership, and usage reviews under governance oversight.