Who should approve SaaS tools from an identity perspective?

Why This Matters for Security Teams

SaaS approval is often treated as a procurement decision, but identity risk is created the moment the tool is connected to mail, storage, chat, source code, or customer data. If the approvers do not include the teams responsible for identity lifecycle, the organisation may buy something that cannot be governed, reviewed, or revoked cleanly. That is how orphaned access, shadow integrations, and over-broad OAuth consent spread into production.

NHIMG research shows that Ultimate Guide to NHIs links identity governance failures to the operational reality that NHIs outnumber human identities by 25x to 50x in modern enterprises. That scale matters because SaaS tools do not just add users, they add tokens, service accounts, API keys, and delegated permissions. Once those identities exist, they must be inventoried, rotated, reviewed, and removed in step with business change.

Current guidance from the NIST Cybersecurity Framework 2.0 supports shared accountability across governance, asset management, and access control rather than leaving approval to a single function. In practice, many security teams encounter SaaS sprawl only after a token leak, a failed offboarding, or a surprise admin role has already been discovered in production.

How It Works in Practice

Identity approval should ask a simple operational question: can this SaaS tool be governed throughout its entire lifecycle, not just purchased? That means confirming how the tool authenticates, what identities it creates, which scopes it requests, where secrets are stored, how access is reviewed, and how revocation works when the contract ends or the owner changes.

A practical review typically includes:

• Business owner approval for the use case and data sensitivity.
• IT or platform review for SSO, SCIM, federation, and tenant configuration.
• Security review for OAuth scopes, token storage, logging, and admin roles.
• Application owner confirmation that access can be provisioned, monitored, and removed.

This is especially important for applications that create non-human identities behind the scenes. NHIMG’s Top 10 NHI Issues highlights how excessive privileges and weak rotation are common failure modes, while the 52 NHI Breaches Analysis shows that compromised credentials and poorly governed integrations repeatedly turn SaaS convenience into an attack path.

For implementation, identity teams should require least privilege, enforce SSO where possible, prefer SCIM-based provisioning over manual account creation, and document a clear revocation path for every privileged integration. If the vendor cannot support audit logs, role separation, or token expiry, the approval should be treated as conditional at best. These controls tend to break down in fast-moving teams that buy SaaS directly with a card, connect it to production data, and never assign an owner who can actually remove access later.

Common Variations and Edge Cases

Tighter identity approval often increases friction for business teams, so organisations have to balance speed against the cost of invisible access paths. That tradeoff is real, especially for low-risk productivity tools where full security review may be excessive. Current guidance suggests risk-tiering the approval path instead of forcing every SaaS purchase through the same workflow.

There is no universal standard for this yet, but a common pattern is:

• Low-risk tools: lightweight approval with mandatory SSO and owner assignment.
• Medium-risk tools: security review of permissions, logs, and lifecycle controls.
• High-risk tools: formal identity and architecture review before purchase.

Edge cases include tools that support only local accounts, tools that request broad delegated consent, and collaborative platforms that create hidden service identities for automation. In those cases, the approver should be the person or group that can answer for identity governance after go-live, not just the person sponsoring the purchase. For identity teams, the approval decision should be anchored in the ability to manage non-human identities safely across joiner, mover, and leaver events.

The practical rule is simple: if no one can explain how access will be provisioned, reviewed, rotated, and revoked, the SaaS tool is not ready for approval from an identity perspective.

Related resources from NHI Mgmt Group

• Who should approve SaaS renewal decisions in identity programmes?
• How can teams reduce risk when multiple SaaS tools overlap?
• Why do SaaS renewals often create identity governance problems?
• Why do SaaS sprawl and app renewals matter to identity governance?