Who is accountable when unsanctioned SaaS stores sensitive business data?

Why This Matters for Security Teams

When an unsanctioned SaaS application stores sensitive business data, the security problem is not just shadow IT. It is an accountability failure across identity, data, and lifecycle ownership. The business may have adopted the tool, IT may control the tenant, and security may be expected to contain the risk after the fact. That split responsibility is exactly how data exposure persists.

This pattern shows up in incidents like the Snowflake breach and the Salesloft OAuth token breach, where access paths and stored data became security liabilities faster than teams could assign ownership. NHI Management Group research also shows that only 20% of organisations have formal processes for offboarding and revoking API keys, while 5.7% have full visibility into their service accounts, underscoring how often ownership gaps become exposure gaps. The relevant control model is described in the NIST Cybersecurity Framework 2.0, which expects clear governance, risk ownership, and recovery responsibilities.

In practice, many security teams encounter the data exposure after the application has already been integrated into workflows, not through deliberate SaaS governance.

How It Works in Practice

Clear accountability starts by assigning a named application owner for every SaaS platform that can store, process, or sync business data. That owner is responsible for approving the use case, understanding what data is collected, and ensuring the application is retired or brought under control when the business no longer needs it. Security owns policy, IT may own identity integrations, but neither should be left with ambiguous operational responsibility.

Effective programmes tie this ownership to three practical controls. First, inventory and classify SaaS applications so the organisation knows where sensitive data is flowing. Second, require explicit offboarding responsibility, including access revocation, token rotation, data export, and deletion. Third, enforce controls outside the IdP, because identity access alone does not govern retention, sharing, or downstream data copies. That is why NHI Management Group emphasises lifecycle visibility in its Ultimate Guide to NHIs, especially where service accounts, API keys, and OAuth grants outlive the business process that created them.

• Define one accountable owner for each SaaS app, even if procurement or IT provided the contract.
• Map what data the app stores, where it is replicated, and which integrations can export it.
• Require offboarding steps for both users and machine access, not just account disablement.
• Use policy controls that can block risky sharing, unmanaged integrations, or stale tokens.

Best practice is to align this with identity governance and recovery playbooks so application retirement, data deletion, and access cleanup are testable, not informal. These controls tend to break down in federated SaaS environments because the tenant owner, the business sponsor, and the data owner are often different people.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance governance certainty against faster SaaS adoption. That tradeoff becomes sharper when business units buy tools directly or when a platform has both user-managed and machine-managed access paths.

There is no universal standard for this yet, but current guidance suggests separating three roles: the business sponsor who requested the app, the technical owner who configures identity and integrations, and the data owner who approves what can be stored. Where SaaS is used for collaboration, analytics, or customer support, accountability may also need to extend to records retention and legal hold. For identity-heavy environments, the NHI risk indicators in the Ultimate Guide to NHIs are especially relevant because OAuth grants, service accounts, and embedded API keys can keep accessing data after the business thinks the app is gone. The same concern appears in breaches such as the BeyondTrust API key breach, where standing credentials made containment harder.

In mature environments, accountability also extends to SaaS-to-SaaS connections, because one unmanaged integration can silently move sensitive data into another tenant. That is where policy enforcement, offboarding, and data governance need to converge.

Related resources from NHI Mgmt Group

• Who is accountable when a vulnerable database leaks sensitive memory?
• Who is accountable when a cloud misconfiguration exposes production data?
• Who is accountable when an agentic browser changes data or permissions?
• What breaks when SaaS agreements do not define data and access boundaries?