What do security teams get wrong about extending data security across Salesforce environments?

Why This Matters for Security Teams

Security teams often underestimate Salesforce because it looks like a single SaaS destination, when in practice it is a data-sharing fabric with multiple clouds, integrations, permissions layers, and downstream exports. The real risk is not just stored records but who can see them, copy them, sync them, and move them into adjacent systems. That is why consistent classification and visibility matter across structured and unstructured data, not just within one console.

This is especially important where sensitive records live in Service, Sales, Marketing, or custom objects, and where data can be exposed through reports, email alerts, connected apps, or API integrations. Current guidance suggests treating Salesforce data exposure as an access and governance problem, not only a storage problem. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for control mapping, but it does not remove the need for Salesforce-specific inspection of field-level sharing and integration paths. In practice, many security teams discover oversharing only after records have already been exported, synchronised, or accessed through a connected app.

NHIMG research shows how quickly token-based access can widen exposure, including the Salesloft OAuth token breach, where OAuth abuse created a path into Salesforce data.

How It Works in Practice

The practical mistake is assuming security can be enforced only at the org level. Salesforce environments need layered controls across data discovery, classification, sharing, retention, and integration governance. A useful operating model is to map where sensitive data enters Salesforce, where it is transformed, and where it exits. That includes records created by users, data ingested from support tools, and content surfaced in attachments, notes, and attachments-like fields.

Security teams should focus on the control points where data becomes visible to broader audiences:

• Field-level security and object permissions, so access is limited to the minimum required role.
• Sharing rules, role hierarchies, and public groups, which can expand visibility beyond the expected team.
• Connected apps, OAuth grants, and API integrations, which can copy data into systems with weaker controls.
• Retention and deletion logic, so stale records do not become permanent exposure points.
• Monitoring and audit logging, so unusual export activity or mass access is visible quickly.

For governance alignment, the CSA Cloud Controls Matrix and ISO/IEC 27002:2022 Information Security Controls are useful for anchoring cloud oversight, but they need to be translated into Salesforce object, field, and integration controls. NHIMG’s Ultimate Guide to NHIs is relevant here because OAuth apps, service accounts, and API keys often become the hidden bridge between Salesforce and the rest of the enterprise. A strong program also checks whether data exports are governed differently from in-app access, since the former often bypasses the controls people assume are in place. These controls tend to break down in heavily integrated Salesforce estates because third-party apps, custom code, and offline exports create visibility gaps that central policy rarely sees.

Common Variations and Edge Cases

Tighter data controls often increase administrative overhead, requiring organisations to balance fine-grained protection against user friction and operational delay. That tradeoff becomes more pronounced in Salesforce environments with many business units, custom objects, or legacy integrations, where one-size-fits-all policies can disrupt legitimate workflows.

There is no universal standard for how deeply every Salesforce deployment should be classified, but current guidance suggests focusing first on the highest-risk combinations: regulated data, external sharing, and connected apps with broad API scopes. A healthcare or financial services deployment may need separate review of support cases, attachments, and notes because those fields often contain data that users never intended to place in a CRM. Similarly, sandbox and test environments are often overlooked, even though production data is frequently copied into them.

One useful rule is to treat Salesforce as part of the wider identity and NHI problem, not just a data loss prevention problem. NHIMG’s State of Non-Human Identity Security shows how limited visibility into OAuth-connected ecosystems remains a widespread issue, which is exactly why Salesforce data controls fail when teams only review human user access. The most common gap is not a missing policy, but a missed path where data leaves Salesforce through a trusted integration and is never reclassified again.

Related resources from NHI Mgmt Group

• What do security teams get wrong about overprovisioning in data-heavy environments?
• What do security teams get wrong about access risk in financial data environments?
• What do security teams get wrong about access reviews for sensitive data?
• What do security teams get wrong about business-context data classification?