SaaS management needs stakeholder governance, not tool sprawl

At a glance

What this is: This is a stakeholder-governance view of SaaS management, with the core finding that effective control depends on coordinated visibility across IT, finance, procurement, legal, and executive decision-makers.

Why it matters: It matters to IAM practitioners because SaaS sprawl creates access, lifecycle, and compliance gaps that look like procurement problems until they become identity problems.

👉 Read Zluri's article on stakeholder collaboration for SaaS management

Context

SaaS management is the discipline of discovering, controlling, and governing the applications people and teams buy, use, renew, and retire. The article’s central claim is that SaaS management only works when multiple stakeholders share the same operating picture, because disconnected decisions create security, compliance, and cost leakage.

For identity teams, the real issue is lifecycle control across applications and access paths. When onboarding, offboarding, renewals, and contract ownership are split across departments, organisations lose the ability to know who still has access, which apps are abandoned, and where compliance exposure is accumulating.

Key questions

Q: What breaks when SaaS management is left to separate teams with no shared ownership?

A: Ownership fragments, and no team has enough context to manage the full lifecycle of an application. Procurement may approve the purchase, finance may track spend, IT may administer access, and legal may review terms, but abandoned apps and stale permissions still persist unless one workflow ties these decisions together.

Q: Why do SaaS sprawl and app renewals matter to identity governance?

A: Because every SaaS application creates identities, entitlements, and offboarding obligations. If renewal and disposal decisions are handled without identity oversight, users can retain access beyond need, duplicate apps remain in use, and audit evidence becomes incomplete. SaaS management is therefore an identity control problem as much as a commercial one.

Q: How do organisations know if SaaS governance is actually working?

A: Look for evidence that inventory, ownership, access review, renewal tracking, and retirement are linked in one process. If finance, IT, procurement, and legal each have partial data but cannot reconcile abandoned apps or expired business need, the governance model is not working.

Q: Who should be accountable when SaaS access persists after offboarding?

A: Accountability should sit with the application owner, supported by IT and the business function that approved the app. If offboarding is not tied to a named owner and an enforced workflow, access can outlive the employee or contractor relationship and become an avoidable governance failure.

Technical breakdown

SaaS lifecycle governance across procurement and IT

SaaS governance is not a single control point. It spans purchase approval, deployment, license assignment, renewal review, and disposal, with IT carrying the operational burden once software enters the environment. The article shows why stakeholder collaboration matters: procurement can negotiate terms, finance can expose waste, legal can enforce contractual constraints, and IT can connect app use to user lifecycle events. Without that coordination, discovery data exists but does not translate into control. The result is shadow SaaS, duplicate apps, and unmanaged access paths that remain active long after business need has changed.

Practical implication: tie SaaS intake and retirement to the same lifecycle workflow so app ownership, access, and renewal decisions are never separated.

Visibility into SaaS apps, usage, and renewal risk

A SaaS management platform is useful when it turns fragmented data into a shared operational view. In the article, that means usage monitoring, renewal tracking, department-level spend, and contract detail all become inputs to governance decisions. This is important because the failure mode is not lack of software, but lack of reconciled evidence. If finance sees spend, IT sees users, and legal sees contracts but no one correlates them, the organisation cannot reliably spot abandoned applications, overprovisioned licences, or unsupported tools with lingering access.

Practical implication: build a single inventory that reconciles ownership, active use, renewal dates, and contract status before each review cycle.

Why SaaS management becomes an identity problem

The article treats onboarding and offboarding as routine IT work, but they are identity lifecycle controls in practice. Every SaaS application introduces accounts, entitlements, and offboarding obligations that must be removed when users change role or leave. When SaaS management is weak, those entitlements persist across systems and create privilege creep, audit gaps, and unnecessary exposure. That makes the discipline relevant to IAM, IGA, and NHI programmes at the same time, because the same lifecycle failure can affect employees, contractors, and service-linked access tied to SaaS integrations.

Practical implication: align SaaS administration with joiner-mover-leaver processes so app access cannot outlive business need.

NHI Mgmt Group analysis

SaaS management fails when organisations treat application inventory as a procurement problem instead of an identity governance problem. The article’s stakeholder model is useful because it shows that spend, compliance, and access decisions are interdependent, not separate workstreams. Once SaaS is widely adopted, ownership fragments unless IT, finance, procurement, and legal work from the same system of record. The practical conclusion is that application governance must be designed as an access and lifecycle discipline, not a buying exercise.

Visibility without lifecycle enforcement creates a false sense of control. Knowing which applications exist, who pays for them, and when contracts renew does not by itself answer who still has access or who should have been removed. That is the control gap this article exposes: discovery is necessary, but it does not revoke entitlements or close abandoned access paths. Practitioners should treat inventory as a starting point, not an endpoint.

Legal and procurement are part of identity risk management when SaaS is the system of access. SaaS contracts, renewal terms, and vendor commitments determine how long an application and its accounts remain in play. If those decisions sit outside the identity programme, lifecycle offboarding becomes inconsistent and audit evidence becomes incomplete. The implication is that identity governance must extend into commercial and legal processes wherever software access is being created or retained.

Lifecycle ownership across SaaS apps is the named concept this article surfaces. In practice, SaaS sprawl becomes dangerous when no single function owns the full path from purchase to disposal. That assumption breaks down as soon as departments can acquire tools independently and users can retain access outside formal review. Practitioners should recognise lifecycle ownership as the control boundary that determines whether SaaS governance is real or performative.

For identity teams, SaaS management is where human access, machine integration, and contract governance meet. Employee accounts, app-specific roles, and integration credentials all appear inside the same SaaS estate. If the organisation cannot connect business ownership to access ownership, it will miss dormant accounts, duplicate apps, and unmanaged permissions. The conclusion is straightforward: SaaS governance must be run as identity governance with commercial inputs, not as a standalone software catalogue.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• For a broader lifecycle lens, read NHI Lifecycle Management Guide for the operational controls that close offboarding and rotation gaps.

What this signals

Lifecycle ownership is the pressure point this article exposes. SaaS programmes often accumulate tools faster than they define accountability, so the next maturity step is not more discovery alone. It is a shared lifecycle model that connects procurement approval, access assignment, renewal review, and retirement across the same application record.

The evidence that secrets and access persist long after an event should push SaaS teams to tighten deprovisioning discipline. When entitlement removal is not synchronized with application retirement, stale access becomes a standing risk rather than an exception.

With 92% of organisations exposing NHIs to third parties, per the Ultimate Guide to NHIs, SaaS governance also needs a supplier boundary. That means external access, integrations, and vendor-managed accounts must be reviewed with the same seriousness as internal user access.

For practitioners

• Assign a single business owner for every SaaS application Require one accountable owner per app who signs off on procurement, access review, renewal, and retirement decisions. Without a named owner, SaaS apps drift into shared responsibility and no one closes the loop when users leave or contracts expire.
• Reconcile SaaS spend with active usage before renewals Compare finance records, usage telemetry, and contract dates in one review cycle so dormant applications and duplicated tools surface before auto-renewal. Use the same data set to identify where access remains active without a business case.
• Embed offboarding into SaaS administration workflows Make SaaS removal part of employee and contractor exit processes so accounts, licences, and application permissions are revoked together. This prevents access from persisting after the business relationship has ended.
• Create a cross-functional SaaS governance review board Bring IT, procurement, finance, and legal into a recurring review of new apps, renewal exceptions, and compliance issues. The goal is to stop individual teams making decisions that expand identity risk in isolation.

Key takeaways

• SaaS management becomes an identity governance issue when application ownership, access, and retirement are split across teams.
• Discovery and spend visibility help, but they do not revoke stale entitlements or close abandoned access paths.
• The practical fix is a shared lifecycle process that links procurement, IT, finance, and legal to named application ownership.

Key terms

• SaaS governance: SaaS governance is the set of controls used to manage software subscriptions, access, ownership, renewals, and retirement. It turns scattered application usage into an accountable operating model so security, finance, procurement, and legal decisions can be made from the same evidence base.
• Identity lifecycle: Identity lifecycle is the full path from account creation to modification, review, and removal. In SaaS environments it covers users, contractors, and linked application access, making it the control layer that prevents stale permissions from surviving beyond business need.
• Application ownership: Application ownership is the assignment of clear accountability for a system’s business use, access decisions, and retirement. It ensures one party can answer who approved the app, who uses it, who reviews it, and who is responsible when access must be removed.
• Shadow SaaS: Shadow SaaS is software adopted or retained outside formal governance processes. It often appears when teams buy tools independently or fail to retire them cleanly, creating hidden access paths, duplicate functionality, and compliance blind spots.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Zluri: SaaS management collaboration across five stakeholder groups. Read the original.