It needs shared ownership. Security teams define the control intent, IAM or IGA teams operationalise access oversight, and application owners validate business need and role context. If one team owns it alone, licence optimisation, access hygiene, and audit evidence tend to fragment.
Why Salesforce governance cannot belong to one team alone
Salesforce governance sits at the intersection of security policy, access administration, and business ownership. If you collapse that into a single team, the programme tends to drift toward either technical enforcement without business context, or business speed without sufficient control. Shared ownership keeps the control model aligned with how Salesforce is actually used, especially where access is tied to roles, integrations, and delegated administration.
That shared model matters because Salesforce is not just a sales tool, it is often a system of record with sensitive customer data, workflow permissions, and automated access paths. Security can set guardrails, but the application team knows which objects, profiles, and processes are legitimate. IAM or IGA can operationalise reviews and lifecycle control in a way that scales. Identity Security Programme Guide is useful here because it frames ownership as an operating model problem, not just a tooling decision.
The practical test is whether each team can answer a different question. Security should answer what the control intent is, IAM or IGA should answer how access is provisioned and reviewed, and application owners should answer whether the requested access matches the business process. That split prevents “access approved because it is convenient” from becoming the default decision rule.
How the ownership split should work in practice
Security should own policy definition, risk acceptance boundaries, and exception handling. IAM or IGA should own the mechanics of joiner, mover, leaver flows, periodic recertification, and evidence generation. Application owners should validate business need, role design, and whether the requested access reflects current process reality. That division gives you one accountable control plane without forcing one team to carry every decision.
For Salesforce specifically, the ownership model should also reflect the difference between licensing decisions and access decisions. A user can be entitled to a licence without needing broad object or data access, and a role can be technically valid without being operationally justified. IAM and Identity Provider Buyer’s Guide is relevant because it reinforces the need to separate identity platform mechanics from the application’s business rules.
Where governance fails, it is usually because one of those layers is missing. Security teams may define a strong standard but lack the business context to retire stale roles. Application teams may know the business process but not the audit trail expectations. IAM teams may run reviews but cannot judge whether a permission is still justified. The right ownership model keeps those judgments connected rather than blended into a single queue.
What breaks when governance is handed to only one function
Single-owner models create predictable failure modes. Security-only ownership often becomes policy-heavy but context-light, which leads to over-restriction, shadow approvals, or exceptions that never close. Application-only ownership often produces permissive access because business urgency wins over control rigor. IAM-only ownership can become administratively efficient while missing whether the access model still reflects real business need.
That risk becomes more serious when Salesforce is integrated with other systems, because access decisions can propagate through connected apps, tokens, and delegated workflows. The more integration-heavy the environment, the more important it is that governance decisions are reviewed from both a security and a business lens. Ultimate Guide to NHIs, Regulatory and Audit Perspectives helps illustrate why auditability and control evidence matter when access paths are distributed across systems.
Another common breakdown is unclear ownership of remediation. If a review finds excessive access, no one should be debating who can revoke it. The governance model should make revocation, role redesign, and exception approval unambiguous. That is what keeps the control from degrading into a reporting exercise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Salesforce governance must limit access to what users need. |
| IA-5 — Authenticator Management | Salesforce access often depends on managed credentials and tokens. | |
| AU-2 — Event Logging | Governance needs audit evidence for access decisions and changes. | |
| Recommendation — Enforce least privilege for Salesforce roles, profiles, and permission sets. Manage Salesforce credentials and tokens through lifecycle controls. Log Salesforce access changes and review evidence for auditability. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Salesforce governance is fundamentally an identity and access control problem. |
| Recommendation — Define shared IAM ownership for Salesforce access, review, and revocation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Salesforce governance requires access control ownership and enforcement. |
| Recommendation — Assign access control ownership and approval rules for Salesforce. | ||
Practitioner Guidance
What to prioritise: define a written RACI for Salesforce access governance before you tune workflows or reports. The highest-value control is not the review itself, but clear ownership for approval, revocation, exception handling, and role maintenance.
What to verify: make sure every access review can produce evidence of business justification, approver identity, and remediation outcome. If you cannot show who validated the role context, the review is only partially defensible.
Decision rule: if a question is about whether access should exist, application ownership should speak first on business necessity; if it is about how access is controlled at scale, IAM or IGA should lead; if it is about policy and risk tolerance, security should lead.
Practitioner takeaway: Salesforce governance works best when no single team owns the whole problem, because the control only holds when policy, lifecycle administration, and business validation stay in the same decision chain.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities in Salesforce?
- How should security teams use IAST and RASP in NHI governance?
- How should security teams implement IAM governance documentation for application onboarding and access reviews?
- How should security teams prioritise NHI remediation in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org