Who should own Salesforce offboarding controls?

Ownership should sit with the identity or IGA function, working from authoritative identity events and business rules. If offboarding is left entirely to application admins, revocation becomes inconsistent and dependent on local process quality. The control must be central enough to ensure removal is complete and timely.

Why This Matters for Security Teams

Salesforce offboarding is not just a cleanup task. It is a control that determines how quickly access disappears after a role change, termination, contractor expiry, or account consolidation. When ownership is unclear, revocation often depends on whether an application admin notices the change, which is too slow for high-value SaaS data. NHI Management Group’s research on Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows how often lifecycle controls fail when they are spread across local teams instead of anchored in identity governance.

The ownership question matters because Salesforce typically sits in a broader identity ecosystem that includes HR events, SSO, privileged access, connected apps, and service accounts. The control should follow the authoritative identity source and the business rule that defines when access must end, not the convenience of the team administering the app. That lines up with the governance direction in the NIST Cybersecurity Framework 2.0, which treats identity lifecycle control as a core security outcome rather than an app-specific chore. In practice, many security teams discover ownership gaps only after a former user still has access to Salesforce records, integrations, or delegated admin paths.

How It Works in Practice

Best practice is to assign ownership to the identity or IGA function, with HR and business owners supplying the trigger conditions and Salesforce admins supporting enforcement details. The IGA team owns the policy, the workflow, the evidence, and the exception process. Salesforce administrators own the platform-specific mechanics, such as permission sets, connected app entitlements, session invalidation, and any custom automation required to remove access cleanly.

That model works because offboarding is an identity event, not an application event. The workflow should start from an authoritative source such as HR termination, contract end, or transfer, then evaluate business rules for immediate disablement, delayed access removal, or manager approval. Where possible, revocation should be automated through workflow or policy-as-code and validated with post-action checks. The relevant question is not who clicks the button, but who is accountable for completeness, timeliness, and auditability.

For Salesforce specifically, teams should review:

• SSO and directory deprovisioning, so the user cannot return through an alternate login path
• Salesforce native user disablement and license reclamation
• Connected apps, OAuth grants, API tokens, and integration users
• Delegated admin rights, permission sets, and permission set groups
• Session revocation and any workflow that removes access from downstream objects or reports

This is especially important because NHI Management Group’s Top 10 NHI Issues repeatedly shows that lifecycle failures and overlong credential validity are among the most common control gaps. In environments where Salesforce is deeply integrated with middleware, CPQ, or custom APIs, offboarding controls break down when access is recreated outside the identity system through integration tokens, shared service accounts, or local exception handling.

Common Variations and Edge Cases

Tighter central ownership often increases coordination overhead, requiring organisations to balance control consistency against local application knowledge. That tradeoff matters because not every Salesforce deployment looks the same. Some use heavy customization, multiple business units, or third-party integrations that require technical input from platform admins even when identity owns the control.

Current guidance suggests a split-responsibility model works best: identity or IGA owns the policy and final accountability, while application admins own the implementation details and exception handling. In mature programs, the offboarding playbook also covers service principals, shared mailboxes, and non-user access paths tied to Salesforce automation. Without that scope, teams can disable a human account and still leave a live integration path behind.

There is no universal standard for this yet, but the practical rule is simple: the team that sees the authoritative identity event should own the control, and the team that understands Salesforce internals should support execution. That is also why lifecycle documentation such as NHI Lifecycle Management Guide matters here. In organisations with federated IT, the control usually fails when each Salesforce org, business unit, or admin team defines its own offboarding logic because revocation becomes uneven and unprovable.

Related resources from NHI Mgmt Group

• Who should own identity-related compliance controls in practice?
• Who should own redundant app cleanup and offboarding?
• Who should own subscription app review and offboarding?
• How do IAM teams decide whether an AI security assistant needs its own access controls?