Permission sets are a mechanism for assigning capabilities. Privilege governance is the discipline of deciding who should hold those capabilities, for how long, with what review, and with what offboarding path. A well-tuned mechanism can still produce poor outcomes if lifecycle and accountability are weak.
Salesforce permission sets: the mechanism for granting capability
Permission sets are the assignment layer. In Salesforce, they let administrators extend a user’s capabilities beyond the baseline profile without changing the user’s primary role structure. That makes them useful for temporary exceptions, project access, and narrowly scoped privilege grants, but it also means they are a delivery mechanism, not a governance decision by themselves.
Because permission sets can be combined, layered, and reused, they are easy to treat as simple administration. The security reality is that they are just the vehicle that turns an access decision into effective capability. If the underlying entitlement model is messy, permission sets can reproduce that mess at scale rather than correct it.
Privilege governance: the discipline around who should have what, for how long
privilege governance sits above the mechanism. It asks whether a capability is justified, who approved it, whether it still needs to exist, how often it should be reviewed, and what happens when the user changes jobs or leaves. That means governance covers assignment, duration, review, recertification, and offboarding, not just the act of granting access.
In practice, privilege governance is the control plane that prevents entitlement creep. A permission set may be technically valid, but privilege governance decides whether it is still appropriate, whether it should be time-bound, and whether the entitlement should be revoked when the business need ends. This is the difference between granting access and governing privilege.
A useful way to think about it is that salesforce permission sets answer “can this user do it?”, while privilege governance answers “should this user still be able to do it, and under what conditions?”. That distinction matters when teams inherit large permission-set libraries, delegate administration, or create one-off exceptions that later become permanent.
How the difference shows up in a Salesforce environment
The practical gap appears when organisations assume that a clean permission-set design equals good access control. Permission sets can be precise, but they do not enforce lifecycle discipline, evidence of review, or removal after role change. Those responsibilities belong to governance processes that track ownership and retention of access over time.
To make the distinction operational, treat permission sets as objects to be managed and privilege governance as the decision process that manages them. One governs the technical entitlement. The other governs the business justification, approval state, review cadence, and deprovisioning path for that entitlement.
That is why privilege governance becomes especially important when access is granted through multiple permission sets, permission-set groups, or exception-based handling. The more composable the mechanism, the easier it is to lose sight of cumulative privilege and the harder it becomes to answer why a user still has a capability months later.
Risk and Threat Considerations
Weak governance around Salesforce permission sets creates privilege accumulation, stale access, and orphaned capabilities after transfer or departure. The risk is not that permission sets exist, but that they become durable access containers with no reliable review or offboarding path, which can expand blast radius if an account is compromised.
Failure mechanism: A capability is granted once, then copied, layered, or left in place after the business need disappears, so the effective privilege outlives the approval that justified it.
Impact: Excess privilege can enable unauthorised data access, modification, or lateral abuse of CRM workflows, especially where admin-like capability or sensitive customer records are involved.
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 NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Permission-set grants need lifecycle ownership, review, and removal over time. |
| AC-6 — Least Privilege | Privilege governance exists to ensure capabilities stay limited to business need. | |
| IA-5 — Authenticator Management | Privilege abuse often follows weak credential and secret lifecycle discipline. | |
| Recommendation — Use AC-2 to govern entitlement assignment, review, and revocation. Apply AC-6 to restrict Salesforce access to only the capabilities required. Manage credentials with IA-5 so access remains revocable and traceable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question contrasts access assignment with governance over who should retain it. |
| A.5.18 — Access rights | Privilege governance depends on granting, reviewing, and removing access rights. | |
| A.8.2 — Privileged access rights | Permission sets can effectively create privileged access that needs tighter oversight. | |
| Recommendation — Define and enforce access-control rules for permission-set governance. Review and revoke access rights on a scheduled, documented basis. Apply privileged-access oversight to elevated Salesforce capabilities. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | The answer hinges on who gets capabilities and how they are removed over time. |
| Recommendation — Issue, audit, and revoke Salesforce access with documented ownership. | ||
Practitioner Guidance
What to prioritise: Separate the inventory of permission sets from the governance record that explains why each entitlement exists. If you cannot quickly answer who approved it, when it expires, and how it is removed, the control is incomplete even if the permission set itself looks tidy.
What to verify: Check for cumulative privilege across multiple permission sets, not just the contents of a single set. The common failure is judging each grant in isolation and missing the effective access created by combinations, exceptions, and inherited administrative practices.
Decision rule: If the access is permanent, sensitive, or difficult to trace back to a current business need, treat it as a governance problem first and an administration task second. The right question is not only whether the permission set can be assigned, but whether it should still be assigned.
Practitioner takeaway: Permission sets are the implementation detail; privilege governance is what keeps that implementation bounded, reviewable, and reversible.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
- What is the difference between Salesforce roles and permission sets?