Who is accountable for SaaS governance when unsanctioned apps and licence waste keep growing?

Why This Matters for Security Teams

SaaS governance fails when ownership is treated as a procurement issue instead of an ongoing control problem. Unsanctioned apps often enter through business self-service, browser extensions, or OAuth consent, and licence waste grows when no one is accountable for access reviews, offboarding, and reclaiming unused seats. That creates security exposure, financial leakage, and audit blind spots in the same control plane.

NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a strong signal that sprawl is not just about cost control but identity risk as well, as discussed in The State of Non-Human Identity Security. When SaaS apps connect to data, calendars, files, or admin APIs, they become part of the NHI estate and must be governed accordingly. NIST guidance also reinforces that governance, asset management, and continuous monitoring belong in the security operating model, not as one-time checks in procurement, as reflected in the NIST Cybersecurity Framework 2.0.

In practice, many security teams discover SaaS governance gaps only after a revoked employee account, a risky OAuth grant, or an audit exception has already exposed the scale of the sprawl.

How It Works in Practice

Effective accountability usually starts with a shared operating model. IT owns the mechanics of provisioning, deprovisioning, seat reclamation, and directory integration. Security owns policy, risk thresholds, monitoring, and exception handling. Business leaders decide which tools are approved for their functions and which spend is justified. Application owners then maintain the inventory for the apps they sponsor. This division matters because SaaS governance breaks when everyone is “consulted” but no one is accountable.

At the control level, teams should classify every SaaS app by business criticality, data access, identity integration, and external sharing risk. The lifecycle model in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because SaaS app accounts, service principals, and OAuth grants should be treated like other non-human identities: discovered, approved, monitored, rotated where relevant, and removed when no longer needed. Security teams should pair that with policy aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls for access review, audit logging, and least privilege.

• Maintain a single inventory of sanctioned apps, shadow apps, and OAuth-connected tools.
• Require a named business owner for each SaaS subscription and integration.
• Review dormant licences, over-provisioned seats, and unused privileged roles on a fixed cadence.
• Detect unsanctioned app sign-ups through SSO, browser, and CASB or identity telemetry.
• Revoke risky tokens, stale permissions, and abandoned vendors as part of normal offboarding.

This approach works best when identity data, procurement data, and usage telemetry are connected. These controls tend to break down in federated enterprises with decentralized buying authority because no single team can see both spend and access paths.

Common Variations and Edge Cases

Tighter SaaS governance often increases coordination overhead, requiring organisations to balance faster business adoption against stronger approval and review discipline. That tradeoff is real, especially in teams that rely on rapid experimentation, contractors, or department-level procurement. Current guidance suggests there is no universal standard for SaaS ownership models, so the control should match the organisation’s risk profile rather than a generic RACI template.

Some environments need additional nuance. In mergers and acquisitions, app ownership can be unclear for months, so security may need temporary control over discovery and remediation while finance reconciles contracts. In high-growth startups, licence waste often comes from rapid hiring and poor offboarding, so IT-led deprovisioning may matter more than formal committee governance. In regulated sectors, the audit trail itself is part of the control, which is why NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant when demonstrating ownership, review cadence, and exception handling.

Security teams should also watch for hidden SaaS risk in integrations. A harmless-looking productivity app can become a high-impact identity dependency if it can read mail, write files, or automate workflows. That is why identity governance, not just spend management, belongs in the accountability model.

Related resources from NHI Mgmt Group

• Who should be accountable when identity teams expand access governance to unstructured data and SaaS activity insights?
• Who should be accountable for governing access across SaaS apps, devices, and AI workflows?
• Who is accountable for identity governance when organisations shift production, suppliers, and workloads in response to disruption?
• Who is accountable when access governance fails in a complex application estate?