Who should be accountable when an employee buys an unsanctioned SaaS app?

Why This Matters for Security Teams

unsanctioned saas is not just a procurement problem. It creates unreviewed identities, hidden integrations, and shadow data flows that bypass the controls used to enforce least privilege, retention, and vendor risk review. Once an employee connects a new app, the organisation may inherit OAuth grants, API keys, and data-sharing paths that security never approved. That makes accountability a governance issue as much as a technology issue.

This is why identity teams, procurement, and legal cannot treat the purchase as a one-off exception. If no control owner is named, the app often persists past the employee’s job change, the vendor’s contract term, or the first incident response cycle. NHI Management Group has seen how quickly unmanaged tokens and app-to-app trust create lasting exposure in cases like the Salesloft OAuth token breach and the BeyondTrust API key breach. The control gap is usually not the purchase itself, but the absence of a defined owner for the identities created by the purchase.

Current guidance from the NIST Cybersecurity Framework 2.0 supports clear governance and accountability for third-party risk, but many organisations still split responsibility so widely that no one is answerable end to end. In practice, many security teams encounter the exposure only after the employee leaves or the app is found during incident response, rather than through intentional oversight.

How It Works in Practice

The practical answer is shared accountability with a single named control owner. That owner is usually not the employee who made the purchase. Instead, procurement, security, and risk each own a slice of the lifecycle: procurement blocks unauthorized spend and contract drift, IAM records any identities or admin access the app creates, and legal or vendor risk reviews the privacy, data residency, and termination terms. Without that split, the organisation cannot reliably revoke access, review residual data, or prove who approved the integration.

For SaaS, the real governance object is the identity footprint, not just the invoice. Every unsanctioned app may introduce SSO links, service accounts, refresh tokens, webhook secrets, and delegated permissions. Those artifacts should be inventoried, tied to an owner, and reviewed against the same offboarding logic used for other Non-Human Identity governance. If the app touches customer or internal systems, security should treat it as an access path that requires recertification and timely revocation, not merely a software subscription.

• Assign one accountable owner for the app, even if several teams approve controls.
• Record all identities the app creates or consumes, including service accounts and tokens.
• Require contract review before production data is exposed.
• Revoke access on employee departure or app retirement, not only on renewal dates.
• Check for hidden integrations during access reviews and vendor inventory updates.

NHI Management Group data shows why this matters: only 20% of organisations have formal offboarding and API-key revocation processes, and only 5.7% have full visibility into service accounts. Those conditions make unsanctioned SaaS a durable identity problem, not a temporary procurement exception. These controls tend to break down in fast-moving teams with self-serve procurement and no central inventory, because no one sees the app’s identities until after access has already spread.

Common Variations and Edge Cases

Tighter control over SaaS purchasing often increases friction for business teams, so organisations must balance speed against governance. There is no universal standard for this yet, especially where employees use low-code tools or AI-enabled SaaS that can create machine identities automatically.

One common variation is the “personal credit card first, approval later” pattern. In that case, accountability should still sit with the business owner who benefits from the tool, while procurement enforces spend controls and security validates identity and data exposure before the app is allowed to persist. Another edge case is when the app is used only for a pilot. Even pilots can create long-lived tokens, and pilots often outlive their original sponsor unless offboarding is mandatory.

For higher-risk environments, current guidance suggests treating unsanctioned SaaS like any other third-party access path and applying the same review discipline seen in breach analyses such as the Snowflake breach and Dropbox Sign breach. Where the app creates autonomous integrations or delegated access, the question becomes who owns the resulting identities, not just who approved the invoice. That is the boundary where shared accountability becomes operationally necessary.

Related resources from NHI Mgmt Group

• Who is accountable when unsanctioned SaaS stores sensitive business data?
• Who is accountable when a shadow SaaS app creates access and cost risk?
• Who is accountable when a third-party SaaS app causes a compliance failure?
• Who is accountable when a SaaS app remains active after it should have been retired?