Shadow IT and SaaS governance expose the limits of ITAM

At a glance

What this is: This is a Zluri podcast-based analysis of shadow IT and SaaS governance that argues spreadsheet-era ITAM no longer matches the scale, trust, and accountability problems created by modern software sprawl.

Why it matters: It matters because unmanaged SaaS creates identity, data, and procurement risk across human access, NHI-adjacent service workflows, and third-party governance in one control gap.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Zluri's discussion of shadow IT and SaaS governance challenges

Context

Shadow IT is not just an inventory problem. It is a governance failure that appears when employees can create software relationships, move data into third-party services, and bypass the organisation's normal control points without a matching lifecycle process. In identity terms, the issue sits at the intersection of access, accountability, and offboarding.

The article's central claim is that traditional ITAM methods, especially spreadsheets and ad hoc review, cannot keep pace with SaaS adoption, third-party data transfer, and the security obligations that remain with the customer. That makes it relevant to IAM, IGA, PAM, and NHI governance because the control gap is not the application itself but the identities and permissions that surround it.

Key questions

Q: How should security teams govern shadow IT in SaaS-heavy environments?

A: Security teams should combine discovery, ownership, and lifecycle control. Discovery identifies unsanctioned apps, but governance only works when every SaaS service has a named owner, an approved data path, and a documented offboarding step. Without those controls, shadow IT becomes a persistent identity and data-management risk rather than a one-time procurement issue.

Q: Why does SaaS adoption create IAM and data governance risk?

A: SaaS adoption creates risk because access, data placement, and accountability are distributed across multiple parties. The organisation still owns the data and the identity decisions around it, even when a vendor hosts the service. That makes IAM, legal review, and procurement part of the same control plane, not separate functions.

Q: What breaks when SaaS is managed only in spreadsheets?

A: Spreadsheets can track inventory, but they do not enforce offboarding, permission changes, or evidence of review. As SaaS sprawl grows, static tracking misses duplicate subscriptions, unapproved tools, and lingering access after an app is no longer needed. The result is visibility without operational control.

Q: Who is accountable when third-party SaaS mishandles company data?

A: The customer remains accountable for how its data is selected, shared, retained, and governed, even when a third party processes it. Vendor contracts may shift operational tasks, but they do not erase the organisation's duty to understand residency, backup handling, subcontractors, and breach obligations. Accountability follows the data owner, not just the service provider.

Technical breakdown

Shadow IT creates an identity and ownership gap

Shadow IT emerges when business users can subscribe to software outside formal procurement and identity workflows. The technical problem is not only unmanaged applications, but unmanaged relationships between people, data, and permissions. Once a SaaS account is created, it often carries its own roles, sharing settings, API connections, and retention rules. If ITAM cannot model those objects, the organisation loses control over who can access the service, where data flows, and who must revoke access when the relationship ends.

Practical implication: tie SaaS discovery to identity ownership so every app has a named business owner and revocation path.

SaaS trust shifts security obligations, not responsibility

Moving data into a SaaS platform does not transfer the organisation's accountability for that data. The provider may host the service, but the customer still owns governance over contracts, classification, access, and breach response obligations. This is why vendor due diligence alone is insufficient. Security teams need to understand data residency, subcontractors, backup paths, and the identity controls that govern administration and support access. Without that, the enterprise may assume the provider's controls cover obligations they still own.

Practical implication: map contractual responsibility to control owners before onboarding a SaaS application.

Spreadsheet ITAM cannot manage SaaS lifecycle risk

Spreadsheets can list assets, but they do not enforce state changes, access revocation, or evidence collection. SaaS governance needs continuous reconciliation between discovered apps, approved apps, assigned users, and active permissions. That includes tracking whether subscriptions are paid by corporate card, whether data is exported elsewhere, and whether a terminated relationship still has live access. A static record does not stop duplicate subscriptions, shadow provisioning, or lingering access after offboarding.

Practical implication: replace static tracking with lifecycle controls that detect, certify, and remove SaaS access continuously.

NHI Mgmt Group analysis

Shadow IT is a lifecycle problem before it is a software problem. The article shows that once business users can self-provision SaaS, the real failure is not discovery alone but the absence of a governed joiner-mover-leaver path for software relationships. That is why ITAM and identity governance must converge on ownership, review, and revocation. Practitioners should treat every unsanctioned SaaS app as an unmanaged identity surface.

Contractual offloading does not remove identity accountability. Zluri's discussion underscores that the enterprise still owns the consequences of data placement, breach exposure, and access management even when a third party hosts the service. That means the old assumption that SaaS equals delegated control is false. Practitioners need governance models that map responsibility across procurement, IAM, and legal review, not just procurement alone.

Spreadsheets are a visibility layer, not a control layer. The article repeatedly points to spreadsheet tracking as a stopgap, but stopgaps cannot enforce access removal, evidence capture, or app disposition. This is the governance gap: known software that remains outside operational control. Practitioners should view spreadsheet ITAM as a detection aid, not as a substitute for lifecycle enforcement.

Shadow IT expands the identity perimeter beyond managed endpoints. The discussion around personal cards, duplicate subscriptions, and ad hoc SaaS sign-ups shows that the enterprise identity surface now includes procurement decisions and user-driven software choice. That widens the operational perimeter from directory management into behaviour, expense, and data movement. Practitioners should align IAM, ITAM, and procurement around a shared control model.

Identity does not stop at the login screen when data moves into SaaS. The article's hospital transcription example illustrates that the security boundary extends into backups, subcontractors, and jurisdictional handling. That makes the relevant concept identity-adjacent data governance, not just authentication. Practitioners should assume that any third-party SaaS relationship can create hidden downstream access paths.

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.
• Our research also shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• For a lifecycle view, the NHI Lifecycle Management Guide explains how provisioning, review, and offboarding reduce identity drift.

What this signals

Shadow IT will keep expanding unless discovery is tied to identity lifecycle controls. The practical issue is not whether employees will adopt new SaaS tools, but whether the organisation can attach ownership, review, and revocation to every one of them. The relevant benchmark is that only 5.7% of organisations have full visibility into their service accounts, which shows how quickly unmanaged identity surfaces outrun manual control. For the governance baseline, teams should align with NIST Cybersecurity Framework 2.0 and the NHI lifecycle guidance in NHI Lifecycle Management Guide.

Shadow IT is becoming a procurement and identity risk at the same time. Once users can create software relationships with personal cards or local approvals, the control problem shifts from software approval to accountability for data movement and access. The organisation needs a shared view across ITAM, IAM, and procurement so that app discovery is matched by contract review and revocation readiness. That is the point where SaaS governance stops being an inventory exercise and becomes an operating discipline.

Teams should expect more pressure to prove where data goes, who can access it, and how quickly it can be removed when a tool is no longer needed. The article's core lesson is that governance fails when ownership is implicit, not when the app is merely unknown.

For practitioners

• Build a governed SaaS discovery process Correlate expense data, SSO logs, browser signals, and procurement records so unsanctioned applications are detected before they become business dependencies.
• Assign identity ownership for every SaaS relationship Require a named business owner, technical owner, and offboarding owner for each application so revocation, review, and exception handling are never ambiguous.
• Review data residency and backup paths before approval Validate where production data, backups, and subcontracted processing occur, and document whether those locations align with contractual and regulatory obligations.
• Replace spreadsheet inventories with lifecycle controls Use a system that can reconcile active users, subscriptions, and sharing settings, then trigger review or removal when an app is unapproved or abandoned.

Key takeaways

• Shadow IT is an identity governance problem because unmanaged SaaS creates untracked access, unclear ownership, and weak offboarding.
• Spreadsheet inventories reveal software sprawl, but they do not enforce control over data residency, permissions, or lifecycle closure.
• The practical response is to combine discovery, ownership, and revocation into one governed SaaS control model.

Key terms

• Shadow IT: Shadow IT is software, services, or integrations used without formal approval or central governance. In practice, it becomes an identity and data problem because access, ownership, and offboarding happen outside the organisation's normal control processes.
• SaaS governance: SaaS governance is the set of controls used to approve, monitor, secure, and retire cloud applications. It includes ownership, data handling, access review, contract oversight, and lifecycle enforcement so that usage stays aligned with policy and accountability.
• Lifecycle control: Lifecycle control is the ability to manage an identity or application from approval through review to removal. For SaaS, it means changes in ownership, access, and data exposure are recorded and acted on instead of left to spreadsheets or memory.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Best Practices 8 Key Learnings about Shadow IT and Rethinking ITAM from Jeremy Boerger. Read the original.