They often assume compliance can be proven by controlling a few obvious records or by reviewing access to the platform itself. In practice, regulated data is scattered across custom objects, workflow artefacts, and files, so the real issue is visibility and prioritisation. If those are missing, compliance reports can look clean while exposure remains.
Why Security Teams Misread Salesforce Compliance Risk
Salesforce compliance failures are usually treated as a permissions problem, but that is too narrow. Sensitive data also lives in custom objects, reports, attachments, workflow artefacts, integrations, and OAuth-connected apps, so a clean-looking access review can miss the actual exposure surface. NIST Cybersecurity Framework 2.0 emphasises continuous identification and protection, not point-in-time assurance, which is why Salesforce needs ongoing data mapping rather than periodic checkbox review.
That gap shows up in NHIMG research on non-human identities as well. The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, while 85% lack full visibility into third-party vendors connected via OAuth apps. In Salesforce environments, that visibility gap matters because compliance evidence can look complete while active data paths remain undocumented.
Teams also underestimate how often the real problem is prioritisation. Regulators and auditors care less about whether every object is neatly labelled and more about whether regulated data is discoverable, access-controlled, retained properly, and monitored for unusual use. In practice, many security teams encounter Salesforce compliance issues only after a review, incident, or audit request exposes data stores they never mapped intentionally.
How Salesforce Compliance Actually Breaks Down in Practice
The practical failure is usually a blind spot in data lineage. Security teams often start with profiles, permission sets, and admin roles, but compliance scope extends to what users and connected systems can read, export, sync, or archive. That means a security review must include custom fields, Apex-driven automation, file storage, reports, sandbox copies, and integrations that move records into downstream systems.
A stronger approach is to treat Salesforce as a governed data ecosystem rather than a single application. Current guidance suggests three layers of control:
- Map regulated data to objects, fields, files, and exported views, then classify where it is stored and where it can move.
- Review non-human access separately from human access, especially OAuth apps, service accounts, and API tokens.
- Use continuous logging and monitoring for exports, bulk reads, permission changes, and unusual integration behaviour.
That matters because the most material risk often comes from the non-human path. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both point to lifecycle control as the practical anchor: discover, classify, approve, rotate, monitor, and revoke. In Salesforce, that means inventorying every connected app and token, checking whether it still has business justification, and validating whether the access it enables is still least privilege.
For governance, NIST Cybersecurity Framework 2.0 is most useful when applied to the full data path, not just the platform login surface. That includes evidence of data minimisation, access review, alerting on anomalous exports, and retention controls across files and replicas. These controls tend to break down in heavily customised orgs with many unmanaged integrations because ownership, data flow, and accountability become fragmented across business teams and system owners.
Common Salesforce Compliance Edge Cases Security Teams Miss
Tighter Salesforce control often increases operational overhead, requiring organisations to balance auditability against business users’ need for fast reporting and automation. That tradeoff is real, especially in mature orgs where compliance depends on custom logic and third-party apps rather than default platform settings.
One common edge case is the “compliant core, non-compliant edge” pattern: core objects are locked down, but exports, file attachments, email archives, sandboxes, and downstream BI tools quietly retain regulated data. Another is delegated administration, where local teams can create access paths that central security never sees until an audit asks for evidence.
Best practice is evolving for connected-app governance, and there is no universal standard for this yet. Security teams should treat OAuth apps, API tokens, and service principals as first-class compliance objects, not just technical plumbing. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is especially relevant here because it frames audit evidence around lifecycle control and visibility, which is the same lens needed for Salesforce compliance. In practice, the hardest failures emerge when a “trusted” integration keeps working long after the business owner has forgotten it exists.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Salesforce compliance depends on knowing all data assets and connected integrations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to limiting regulated data exposure in Salesforce. |
| OWASP Non-Human Identity Top 10 | NHI-01 | OAuth apps and API tokens are non-human identities that often drive Salesforce exposure. |
Inventory Salesforce objects, files, exports, and integrations as part of a living asset map.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
