Who is accountable for securing SaaS integrations that create blind spots across an organisation?

Why This Matters for Security Teams

SaaS integrations often create an accountability gap because the connection looks lightweight while the actual risk sits in OAuth scopes, service accounts, API keys, logging, and revocation paths. When a vendor app can read mail, move data, or trigger workflows, the organisation that approved the integration owns the security outcome, even if the vendor supplies inconsistent telemetry. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which makes this a governance issue, not just a connectivity issue.

This is why incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach matter to ordinary SaaS governance. They show how a single integration can become a bridge into multiple systems when access scope is broad and oversight is weak. Security teams should map accountability across identity, application, and business ownership rather than assuming the vendor’s default controls are enough. In practice, many security teams encounter these blind spots only after data has already moved through an over-permissioned integration.

How It Works in Practice

Accountability should follow control, not convenience. The team that approves a SaaS integration should define the minimum security baseline before the connection goes live: what data the app can reach, which identities it can impersonate, how logs are retained, who reviews alerts, and how access is revoked. That baseline should be enforced through identity governance, not informal vendor assurances.

Current guidance aligns well with NIST control families, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats access management, auditing, and configuration oversight as core responsibilities. For integration-heavy environments, the practical pattern is to assign one accountable owner for the SaaS relationship, one technical owner for the identity configuration, and one operational reviewer for ongoing evidence. That division matters because vendor consoles often show only partial data, while the organisation still owns the risk of stale tokens, hidden app consents, and excessive scopes.

• Inventory every SaaS-to-SaaS and SaaS-to-data-store connection.
• Classify the integration by data sensitivity, scope, and authentication method.
• Require least-privilege scopes and short-lived credentials where possible.
• Log consent grants, token issuance, permission changes, and revocation events.
• Review integrations on a fixed cadence and remove unused or unverified connections.

The governance model is reinforced by research in the Ultimate Guide to Non-Human Identities, which highlights how often NHIs remain unrotated, over-privileged, or poorly visible. These controls tend to break down when shadow IT teams connect SaaS tools directly to production data because no one maintains an authoritative owner, scope, or revocation path.

Common Variations and Edge Cases

Tighter integration control often increases friction for product teams, requiring organisations to balance speed of adoption against review depth and operational overhead. That tradeoff becomes sharper when the integration is user-installed, embedded through a marketplace, or managed by a third party that resells the SaaS service. In those cases, there is no universal standard for this yet, but current guidance suggests the internal organisation still owns the risk accepted on its behalf.

Edge cases usually appear when multiple teams share a tenant, when delegated admin rights blur responsibility, or when the SaaS platform exposes incomplete audit trails. A common mistake is treating vendor SOC reports as a substitute for internal evidence collection. They are useful inputs, not accountability transfers. Another gap appears in multi-tenant environments where one business unit approves an app that later gains access to another unit’s data because identity boundaries were never separated. The Snowflake breach and the Dropbox Sign breach both illustrate how valid integration pathways can still create organisational exposure when ownership and review are weak.

For organisations that rely on contractor-led administration or federated business ownership, the practical answer is to centralise policy and decentralise execution. Security should define the rules, application owners should evidence them, and identity teams should enforce revocation and review. That is the only reliable way to close SaaS blind spots when vendors cannot provide complete or consistent data.

Related resources from NHI Mgmt Group

• Who should be accountable for SaaS-to-SaaS integration risk when business units create the connections?
• Why do SaaS applications create blind spots for IAM teams?
• Who is accountable when noisy detections create blind spots?
• Why does unmanaged AI usage create blind spots for SaaS security and identity controls?