Salesforce Permissions Audit Checklist (38 Points)

Most Salesforce permission failures share a small set of root causes: 26% of users hold System Administrator profile, 14 Integration Users have admin access, 234 permission sets have not been assigned to a user in 12+ months, and the runtime user your integrations call as can Modify All Data.

This is the 38-point checklist for finding those root causes in your org. Run it manually (allow 4-6 hours for a thorough pass) or let Clientell's free Permissions Audit score all 38 automatically in 10 minutes.

Profile hygiene (8 checks)

1. Total profile count below 25. Above 25 indicates profile sprawl. Most orgs we audit have 30-60 profiles, each a near-copy of one above it.
2. Users with System Administrator below 5% of total. Healthy benchmark. Most orgs sit at 20-30%. Each SysAdmin user is a permanent backdoor.
3. No "temporary admin" users still active. Project-grant SysAdmin from a 2021 implementation that never got revoked.
4. Every active profile has at least one assigned user. Profiles with zero users are pure technical debt. Safe to remove.
5. No profile has both "Modify All Data" AND "View All Data" unless explicitly justified. Either-or, not both, for non-admins.
6. API Enabled is not granted at the profile level for human users. Integration users need API Enabled. Sales reps and CSMs do not.
7. "View All Users" is restricted to compliance and IT roles. Otherwise users can browse the org directory unnecessarily.
8. "Manage Users" is restricted to genuine user-admin roles. Most orgs have this granted broadly. Tighten to 2-4 named users.

Integration users (6 checks)

9. Every integration has its own dedicated Integration User. No shared service accounts.
10. No Integration User has the System Administrator profile. Custom least-privilege profile only.
11. Integration User passwords are managed by a secret store, not stored in the integration config. Vault, AWS Secrets Manager, or equivalent.
12. Integration Users are excluded from MFA enforcement only when API-only and certificate-authenticated. Otherwise enforce MFA on them.
13. Each Integration User has an explicit allow-list of IP ranges or named credentials. Not "any IP".
14. Integration User actions are logged via Setup Audit Trail or a dedicated audit object. SOC 2 CC7.2 requirement.

Permission set hygiene (8 checks)

15. Permission sets are used in place of profile customization for one-off access grants. Profile for baseline, permission sets for everything else.
16. No permission set has been unassigned for 12+ months. If nobody is using it, archive it. Median org has 234 such permsets.
17. Permission set names follow a documented convention. No "Sarahs_Test_PSET" in production.
18. Permission Set Groups consolidate related permsets where applicable. Reduces assignment overhead by 60-80%.
19. Each permission set has a documented owner and purpose. Description field populated, not blank.
20. No permission set grants "Modify All Data" without an explicit business justification documented.
21. Permission set assignments are reviewed quarterly. SOC 2 / ISO 27001 expectation.
22. Object-level permissions in permsets do not contradict the profile they layer on. Otherwise users have inconsistent access.

Role hierarchy + sharing (6 checks)

23. Role hierarchy has no orphan nodes. Roles with no users and no children below them.
24. Role hierarchy reflects organizational reality. Not the 2021 org chart.
25. OWD (Org-Wide Defaults) for sensitive objects is Private or Read Only. Not Public Read/Write for Account, Opportunity, Case in regulated industries.
26. Sharing rules do not silently grant broad access. Each rule reviewed for unintended scope.
27. Manual record sharing is logged or restricted. Otherwise records can be shared in ways nobody knows about.
28. External users (Communities) have their own sharing model, separate from internal. No accidental cross-org visibility.

Sensitive field protection (5 checks)

29. PII fields (SSN, DOB, government ID) are encrypted via Shield Platform Encryption or Classic Encryption.
30. PII field-level security is set to "Read Only" or hidden for non-relevant profiles. Sales reps do not need SSN access.
31. Financial fields (revenue, contract value, custom fields with $ data) have field-level security audited.
32. PHI fields (for HIPAA-regulated orgs) follow 164.312(c) integrity controls. Audit logged, change-tracked.
33. Custom fields holding sensitive data have explicit Description field documentation noting the classification.

Login security (5 checks)

34. MFA is enforced on all human users via Login Flow or Profile setting. Not optional.
35. Login IP ranges restrict access to corporate networks and VPN where applicable.
36. Session timeout is set to a defensible value (2-12 hours depending on role sensitivity).
37. Salesforce Authenticator or hardware key (not just SMS) is required for elevated roles.
38. Failed login attempts trigger lockout and alert. SOC 2 CC6.6.

Scoring

Each check passes (1 point) or fails (0). Total possible: 38.

The median 4-year-old mid-market org we scan lands at 19/38 on first pass. Healthy orgs land at 33+. The gap is usually 8 weeks of focused work, much of which can be agent-automated.

Run it automatically

The 38 checks above are exactly what the free Salesforce Permissions Audit scores in 10 minutes. Each failing check ships with a sandbox-tested one-click fix and the SOC 2 / ISO 27001 control it maps to.

For the day-by-day audit workflow that takes a failing org from 19 to 33+, see the Salesforce Audit Workflow Playbook.