Who is accountable when a connected app exposes Salesforce data?

Accountability sits with the organisation that allowed the connection, because the business owns the risk created by granting access to sensitive systems. Security, IAM, and application owners should share responsibility for approval, monitoring, and revocation. Governance must cover inventory, permission review, and exception handling so third-party access does not become unmanaged.

Why This Matters for Security Teams

When a connected app exposes Salesforce data, the practical question is not just who clicked approve. It is who accepted the business risk of extending access to a sensitive system, who monitors that access, and who can revoke it fast enough when the app changes behaviour. That accountability sits with the organisation that enabled the connection, because OAuth grants and API integrations are operational privileges, not a vendor-side problem. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often third-party exposure becomes a governance failure rather than a one-off technical event.

Security teams often underestimate how quickly a harmless-looking integration turns into a data access path with wide blast radius. Salesforce is usually connected to other business systems, which means one granted token can expose records, automate exports, or enable lateral movement into downstream workflows. NHI management discipline matters here: the Ultimate Guide to NHIs — Key Research and Survey Results notes that 92% of organisations expose NHIs to third parties, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

In practice, many security teams encounter the real risk only after a connected app has already exported data, persisted tokens, or been inherited by an ownerless business unit rather than through intentional review.

How It Works in Practice

Accountability should follow the control points in the access lifecycle. Business ownership sits with the team that approved the integration for a specific use case. Security owns policy, risk review, logging expectations, and exception handling. IAM owns token governance, consent boundaries, and revocation mechanics. Application owners own the data scope the app can reach and the operational review of whether the access is still justified.

That shared model works only if the organisation treats connected apps like any other privileged non-human identity. The app needs an inventory record, a defined purpose, a named owner, scoped permissions, and a review cadence. Where possible, prefer least-privilege scopes, short-lived tokens, and conditional approval for high-risk data sets. NIST guidance on access control and accountability in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this model through control families focused on access enforcement, auditing, and configuration management.

Operationally, teams should ask four questions for every connected app: what data does it touch, who approved it, when was it last reviewed, and how is it revoked. That review should include app-to-app links, because the initial Salesforce connection may only be the first hop in a broader chain. NHI Mgmt Group’s Salesloft OAuth token breach illustrates how token abuse can translate into Salesforce data exposure when governance is weak. These controls tend to break down in sprawling SaaS estates with delegated administration, where multiple business units can approve integrations without a single revocation authority.

• Assign one accountable owner for each connected app, even if many teams use it.
• Review OAuth scopes and API permissions against the minimum data required.
• Log approvals, token issuance, and revocation actions in a central inventory.
• Revalidate access after vendor changes, mergers, or business process changes.

Common Variations and Edge Cases

Tighter control over connected apps often increases approval friction, so organisations have to balance speed against the risk of unmanaged data exposure. The hard case is not a clearly malicious app, but a legitimate one that starts with narrow access and later expands through new features, inherited scopes, or administrator consent. Best practice is evolving here, and there is no universal standard for how often every SaaS integration should be re-certified.

Special treatment is needed for partner apps, low-code automation, and marketplace add-ons because ownership may be split across procurement, IT, and the business sponsor. In those cases, accountability should still land with the organisation that allowed the connection, but exception handling must be explicit: time-bound approvals, documented compensating controls, and a clear revocation trigger. Guidance from the Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here because third-party exposure is common and long-lived credentials remain a major weakness.

The most difficult edge case is service-account sprawl behind the app. If a connected app uses secondary credentials, shared admin tokens, or undocumented sync jobs, accountability becomes blurred unless those identities are also inventoried and rotated. That is where many organisations discover that the app was approved correctly, but the downstream identity model was never governed.

Related resources from NHI Mgmt Group

• Who is accountable when GenAI traffic is allowed to bypass policy controls and exposes sensitive data?
• Who is accountable when a connected app grants unauthorised access to data?
• Who should be accountable when a shadow app exposes company data?
• Who is accountable when a connected health app mishandles patient data?