Why Permission Set Audits Matter More Than Ever
If you manage a Salesforce org with more than a handful of users, you've almost certainly accumulated permission sets that no one fully understands anymore. Someone needed access to a custom object three years ago. A consultant stood up an integration and created a permission set with broad API access. A well-meaning admin cloned a permission set "just to test something" and it's still assigned to 40 users.
This is how orgs quietly drift into a state where no one can confidently answer the question: who has access to what?
A Salesforce permission set audit isn't just a compliance exercise. It's one of the highest-leverage activities an admin can perform to reduce security risk, simplify their permission model, and regain control of their org. Here's how to do it properly.
Step 1: Export Your Current Permission Set Assignments
Start by pulling a complete picture of what's assigned and to whom. In Setup, navigate to Permission Sets and review the list. For each permission set, click into it and review the "Manage Assignments" section to see assigned users.
For a more scalable approach, run a SOQL query against the PermissionSetAssignment object:
SELECT Assignee.Name, PermissionSet.Name, PermissionSet.Label FROM PermissionSetAssignment WHERE PermissionSet.IsOwnedByProfile = false
Export the results to a spreadsheet. This gives you the raw data you need: every non-profile permission set and every user it's assigned to. Pay attention to the row count — orgs with more than 500 assignments often have significant cleanup opportunities.
Step 2: Identify Permission Sets With No Assignments
Unassigned permission sets are noise. They clutter your Setup pages, confuse new admins, and create ambiguity about whether they're still needed. Query for permission sets that have zero assignments:
SELECT Id, Name, Label FROM PermissionSet WHERE IsOwnedByProfile = false AND Id NOT IN (SELECT PermissionSetId FROM PermissionSetAssignment)
Review each one. If it was created for a project that's been completed, or for a user who's been deactivated, document it and flag it for deletion. Don't delete immediately — you want a review period in case something is referencing it downstream.
Step 3: Audit Object and Field-Level Permissions
This is where the real work begins. For each active permission set, review what it actually grants. Focus on:
- Object permissions: Does this permission set grant Create, Read, Edit, or Delete on objects it shouldn't? Look for broad access to Account, Contact, Opportunity, or any object containing sensitive data like financial records or PII.
- Field-level security: Are sensitive fields (SSN, salary, revenue, margin) exposed through this permission set? Field-level access is frequently overlooked because it requires clicking into each object individually.
- System permissions: Check for dangerous system permissions like "Modify All Data," "View All Data," "Manage Users," or "Author Apex." These should be limited to a very small number of admin-level permission sets.
- App permissions and custom permissions: Review whether connected app access or custom permissions have been granted that are no longer needed. ## Step 4: Cross-Reference With Profiles One of the most common issues we see in org audits is permission stacking — where a user's profile already grants access that a permission set is duplicating. This isn't just redundant; it makes it impossible to reason about what a user can actually do.
For each heavily-used permission set, compare its grants against the profiles of the users it's assigned to. If a permission set grants Read access to the Account object but every assigned user already has that through their profile, the permission set is adding complexity without adding value.
The goal is to have a clean, intentional permission model where profiles handle baseline access and permission sets handle exceptions and elevations.
Step 5: Check for Permission Set Groups
If you're using Permission Set Groups (and you should be, for any org on Enterprise Edition or above), audit those as well. Groups can mask what individual permission sets are doing because the effective permissions are the union of all included sets.
Map out each group's composition. Look for groups that include permission sets with overlapping grants, or groups that have grown to include so many sets that they effectively grant admin-level access.
Step 6: Review Against Your User Role Matrix
Every org should have a documented user role matrix — a table that maps each business role (Sales Rep, Sales Manager, Support Agent, Finance Analyst) to the Salesforce access they need. If you don't have one, building it is a critical prerequisite to a meaningful audit.
With your matrix in hand, compare what each role should have access to versus what they actually have. The gaps in both directions matter:
- Over-provisioned access is a security risk and a compliance liability.
-
Under-provisioned access means users are working around the system, which creates data quality issues.
Step 7: Document and Remediate
A good audit produces a clear remediation plan, not just a report. For each finding, document:
What the issue is
Which users or permission sets are affected
The recommended fix
The priority (security risks first, cleanup second)
Implement changes in a sandbox first. Test with affected users. Then deploy to production with a rollback plan. Permission changes can break integrations, page layouts, and validation rules in ways that aren't immediately obvious.
How Often Should You Audit?
We recommend a full permission set audit quarterly, with lightweight reviews monthly. Any time you onboard a new team, deploy a major feature, or respond to a security incident, an ad-hoc audit should be part of the process.
The reality is that most orgs don't audit often enough. Permission sets accumulate like sediment — slowly, invisibly, and with compounding risk. By the time someone notices, the cleanup is significant.
Let Our Team Handle It
A thorough permission set audit for a mid-size org takes 20-40 hours of focused admin work. Our practice has refined a methodology that covers every dimension described above, plus integration-specific permission analysis and compliance mapping for SOC 2, HIPAA, and SOX environments.
If you'd like our team to assess your org, reach out at contact@orgdoc.dev.
Need a second opinion on your Salesforce org? Request a diagnostic.
Top comments (0)