Why does unmanaged SaaS create both financial waste and security risk for clients?

Unmanaged SaaS drives cost waste because organisations keep paying for licenses and premium tiers they do not fully use. It also creates security risk by expanding shadow IT, reducing visibility, and weakening control over data and access. When no one can see who is using what, compliance gaps and account sprawl become harder to detect and correct.

How unmanaged SaaS creates spend without value

Unmanaged SaaS wastes money because procurement and operations lose the ability to distinguish active use from dormant subscription spend. Licenses can remain assigned after onboarding changes, premium tiers can persist after the original use case fades, and duplicate tools can coexist without ownership. The result is recurring spend that looks justified in aggregate but is not tied to actual business value.

A useful way to think about the cost problem is that SaaS sprawl is not just about too many apps, it is about too many buying decisions with no enforced retirement path. When no one owns application inventory, renewal review, or usage validation, finance may keep paying for capacity that users, teams, or integrations no longer need.

For a broader view of how inventory, ownership, and deprovisioning failures create long-lived exposure, see NHI Lifecycle Management Guide and Top 10 NHI Issues. The same control failure pattern shows up in SaaS environments: what is not inventoried is difficult to govern, and what is not governed is difficult to retire.

Why unmanaged SaaS becomes a security problem

Security risk rises when SaaS is adopted outside the normal review path because visibility breaks down across users, permissions, and data flows. Shadow IT can create unsanctioned access paths, while integrations and shared accounts can persist after the original owner has lost context. That makes it harder to answer basic questions such as who can access the system, what data is stored there, and which third parties are connected.

The practical danger is not only that an application exists outside policy, but that its access model often expands quietly. Over time, this can produce account sprawl, excessive permissions, and weak offboarding discipline. The same failure pattern is visible in credential and token abuse incidents, where persistent access material is easier to miss than a normal user account.

That is why incidents involving OAuth tokens, API keys, and service accounts are especially relevant to unmanaged SaaS, including the Salesloft OAuth token breach and the Dropbox Sign breach. They illustrate how an overlooked SaaS integration can expose data well beyond the original app boundary.

What practitioners should do first

Start with discovery, then separate business-critical SaaS from opportunistic or redundant tooling. The most important control question is not just “is the app approved?” but “who owns it, what data does it touch, and how is access removed when the owner, team, or use case changes?” If those answers are missing, the system is already a governance risk, even if no incident has occurred.

What to verify: Review license assignment, admin roles, connected apps, and dormant accounts together rather than as separate exercises. A SaaS product with low user counts can still be high risk if it holds sensitive files, has broad OAuth consent, or contains stale privileged access.

Decision rule: If a SaaS application has no named owner, no offboarding process, or no visibility into connected identities and permissions, treat it as both a cost-reduction candidate and a security remediation item. Where the service supports tokens, keys, or other long-lived access material, prioritise access review and revocation before debating feature usage.

Practitioner takeaway: The right control objective is not to eliminate SaaS growth, but to make every subscription observable, owned, and easy to retire before it becomes both sunk cost and unreviewed access.

Risk and Threat Considerations

Unmanaged SaaS creates a compounded risk because financial waste and security exposure usually come from the same root cause, lack of inventory and ownership. The longer a service sits outside review, the more likely it is to accumulate stale accounts, overbroad permissions, and forgotten integrations that continue to move data.

Failure mechanism: Shadow adoption and missing lifecycle control allow subscriptions, identities, and connected applications to outlive their intended use, which turns ordinary app sprawl into persistent access sprawl.

Impact: Organisations can pay for dormant licenses while also increasing the odds of unauthorised access, compliance gaps, and difficult-to-detect data exposure across business units and third-party connections.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and DORA and PCI DSS v4.0 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 1 — Inventory and Control of Enterprise Assets	Unmanaged SaaS is fundamentally an inventory blind spot.
	CIS 5 — Account Management	SaaS waste and risk both worsen when accounts are not provisioned and removed cleanly.
Recommendation — Maintain a current SaaS inventory and remove or review unsanctioned services. Review and disable stale SaaS accounts and owners on a defined cadence.
NIST CSF 2.0	GV.RM — Risk Management Strategy	SaaS sprawl creates combined financial and security risk that needs governance.
	ID.AM — Asset Management	Discovery and ownership are central to controlling unmanaged SaaS.
	PR.AA — Identity Management, Authentication, and Access Control	Unmanaged SaaS often hides excessive access and weak offboarding.
Recommendation — Incorporate SaaS sprawl into enterprise risk and renewal governance. Inventory SaaS applications, owners, and data flows before renewal decisions. Enforce least-privilege access and remove stale SaaS entitlements promptly.
OWASP Non-Human Identity Top 10	NHI-01 — Lifecycle and Ownership	SaaS sprawl often includes unmanaged non-human access and missing ownership.
	NHI-03 — Visibility and Discovery	The key failure in unmanaged SaaS is lack of visibility into apps and access paths.
	NHI-07 — Secrets and Credential Management	Unmanaged SaaS often leaves tokens and keys exposed or unrecovered.
Recommendation — Assign owners and enforce lifecycle reviews for SaaS-connected identities and credentials. Discover SaaS apps, integrations, and secrets before they become blind spots. Rotate and revoke SaaS tokens, keys, and other secrets when ownership changes.
DORA	Article 28 — ICT Third-Party Risk Management	SaaS is a third-party dependency whose unmanaged use creates operational and security risk.
Recommendation — Govern SaaS providers as third-party ICT dependencies with clear ownership and oversight.
PCI DSS v4.0	Req. 7 — Restrict Access by Business Need to Know	Unmanaged SaaS often expands access beyond business need.
Recommendation — Limit SaaS access to the minimum needed for each role and use case.

Practitioner Guidance

What to prioritise: Put SaaS inventory and access ownership in the same review cycle. If finance only sees renewal cost and security only sees login activity, the organisation will miss the link between waste and exposure.

Common mistake: Treating usage reports as proof of control. A low-usage app can still be a high-risk app if it retains admin rights, stale tokens, or sensitive data with no revocation workflow.

What good looks like: Every material SaaS app has a named owner, a reviewed access model, a defined retirement trigger, and a documented process for removing users, integrations, and credentials when the service is no longer needed.

Practitioner takeaway: SaaS governance works when procurement, identity, and security operate from the same inventory, otherwise waste and risk will compound in the same blind spot.