Who should own Salesforce licence governance?

Why This Matters for Security Teams

Salesforce licences are not just a procurement line item. They are a proxy for access, data exposure, and downstream entitlement sprawl across CRM records, integrations, and automation. If ownership sits only with finance, teams can see spend but miss whether a user, service account, or connector still needs access. NHI Management Group’s The State of Non-Human Identity Security shows why identity governance matters: 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks.

The same pattern applies to SaaS licences. Unused accounts, stale assignments, and unmanaged connected apps become security debt that looks like cost waste until it becomes an incident. A governance model that separates budget authority from access authority usually fails because neither team owns the review loop end to end. Current guidance from the NIST Cybersecurity Framework 2.0 favours clear accountability for access decisions, not just spend tracking. In practice, many security teams encounter licence abuse only after an offboarding miss or a compromised account has already exposed Salesforce data.

How It Works in Practice

Operationally, ownership should be split by function but unified by process. IAM or IGA should own entitlement logic: who gets a Salesforce licence, what role or permission set is required, how long access should last, and what evidence is needed for approval. SaaS operations should manage platform configuration, licence pools, and technical deprovisioning. Finance should monitor cost, utilisation, and renewal pressure, but not make the final decision on whether access remains justified.

The practical control point is the entitlement review. That means a recurring workflow that reconciles active users, deactivated users, service accounts, delegated admin access, and connected apps against business justification. It should also include offboarding triggers from HR and, where relevant, JIT access for temporary need rather than standing licences. This is consistent with the lifecycle approach in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which treats identity creation, use, review, and retirement as a single governance chain.

• Use IAM or IGA to define licence eligibility and access review criteria.
• Use SaaS operations to remove licences, revoke sessions, and confirm deprovisioning.
• Use finance to flag idle spend, but not to approve access exceptions on its own.
• Record approvals, revocations, and exceptions in one auditable workflow.

For Salesforce environments with many integrations, this matters even more because a licence can be attached to automation, API access, or delegated admin capability. The governance owner must therefore understand both human and non-human entitlements, not just seat counts. These controls tend to break down when licence ownership is spread across business units with no single review cadence, because orphaned accounts and stale permission sets persist unnoticed.

Common Variations and Edge Cases

Tighter licence governance often increases coordination overhead, requiring organisations to balance cost control against operational speed. That tradeoff is real in sales teams, partner portals, and seasonal hiring patterns, where a hard approval process can slow onboarding. Current guidance suggests using policy tiers: standard roles get automated approval, exceptions require IAM review, and high-risk access needs additional sign-off.

There is no universal standard for this yet, especially when Salesforce is tied to custom objects, external communities, or automation that behaves like a non-human identity. In those cases, governance should extend beyond named users to connected applications, integration users, and API tokens. The risk is visible in incidents such as the Salesloft OAuth token breach, where adjacent access paths created Salesforce exposure that seat management alone would never catch. Best practice is evolving toward joint ownership, but with a single accountable control owner: IAM or IGA for entitlement decisions, backed by SaaS operations for execution and finance for spend oversight.

Related resources from NHI Mgmt Group

• Who should own software licence governance in an organisation?
• Why do SSO tools often fail to solve access governance on their own?
• Who should own SaaS governance when access, licensing, and renewals overlap?
• Why do authentication tools fail to solve access governance on their own?