Salesforce security audits fail for a predictable reason: they treat the org as a static system. But users are added, integrations change, consultants come and go, and permission sets accumulate without anyone signing off. A security audit done 18 months ago is not a current security posture.
This checklist covers every surface area a Salesforce admin needs to examine — from login IP ranges to dormant service accounts to OAuth-connected apps that are still consuming data. It has 47 items. You don't need to run it all at once. Run it in sections, fix what you find, repeat quarterly.
1. User Access & Authentication
Start with identity — before anything else. Who can log in, how they authenticate, and whether their access is current and intentional.
User Accounts 12 items
- Identify all Active user accounts that have never logged in ⚠ warning
- Flag users with Last Login > 90 days who are still Active
- Review and deactivate all Inactive users with Last Login > 180 days
- Identify users with no active permission set assignments — they have profile-level access only and may be over-provisioned
- Check for users who have both a Standard Profile and a Permission Set that together grant Modify All on any object
- Audit Shared Accounts — multiple people logging in as one user — and move to individual accounts with sharing rules
- Verify that all System Administrator profiles are limited to 2–3 named individuals with no shared credentials
- Check that no user has both "Modify All Data" and API Enabled — that combination is the equivalent of a database admin key
- Review users created within the last 30 days for legitimacy — new accounts are a common entry point in social engineering attacks
- Confirm that all user records with API-only access (API User permission, no UI login) are service accounts with no human owner
- Audit the User Role hierarchy — does the top-level role have any orphaned assignments?
- Check that no user has a Role assigned that doesn't match their actual function
Why dormant accounts are a security risk in 2026
A dormant account with valid credentials and Active status is an attacker-ready backdoor. It won't trigger unusual login alerts because it's been quietly logging in for years, and it likely has permissions nobody has reviewed since it was created.
Salesforce's Login History shows last login per user. Cross-reference that list against Active users in Setup. Anyone who hasn't logged in since the previous quarter review window is a candidate for deactivation — not deletion, deactivation. Keep the record for audit trail.
2. Permission Sets & Profile Hygiene
Profiles define what a user can do by default. Permission sets add to that baseline. Between the two, a Salesforce admin can grant very precise access — or very imprecise access that drifts into dangerous territory.
Permission Sets 10 items
- Export the full permission set inventory — count them, note creation date, note last-modified date
- Flag permission sets assigned to 5 or fewer users where the name doesn't clearly indicate a current business function ⚠ warning
- Review permission sets with "API" in the name — API Enabled and Manage API permissions compound across permission sets
- Check for permission sets that include "View All Data" or "Modify All Data" — these grant cross-object access that bypasses sharing rules
- Identify permission sets that grant "Manage Users" — only admins and specific service accounts should have this
- Review permission sets with custom object Create/Edit/Delete permissions where the object contains sensitive data (PII, financial, healthcare)
- Check for permission sets created more than 24 months ago that haven't been modified since their creation date
- Identify permission sets used as test configurations — created in a sandbox, copied to production, never cleaned up
- Review all permission set assignments for users who have left the company — cross-reference against your HR system or offboarding checklist
- Flag permission sets that grant Field-Level Security on sensitive custom fields (SSN, bank account, DOB) — verify the field itself is also protected
Profiles 7 items
- Identify all active profiles — count them, note which are standard Salesforce profiles vs. custom
- Flag profiles assigned to more than 25 users — large-profile assignments make granular access control harder
- Review the "System Administrator" profile — confirm all assignees are current, no shared credentials ⚡ critical
- Check for deprecated profiles (e.g., "Chatter Free", "Chatter External") still assigned to active users in production
- Verify that all custom profiles have a clear owner — someone responsible for reviewing and maintaining it
- Audit the Login Flow assignments — are any login flows tied to a specific user or permission set that no longer exists?
- Review session settings at the profile level — check Session Timeout, ForceLogout on refresh, and Lock sessions to domain
Run the Permission Auditor Right Now
Inventory all permission sets, flag low-assignment and over-privileged assignments, and get an exportable cleanup priority list. No Salesforce credentials required.
3. Sharing Rules & Org-Wide Defaults
Sharing rules determine who can see whose records. Org-wide defaults (OWD) set the baseline. An OWD set to Public Read/Write on a custom object containing customer data is a silent data exposure that most security audits don't catch until there's a breach.
Sharing Configuration 9 items
- Export all Org-Wide Default settings — check every standard and custom object
- Flag any custom object with OWD set to Public Read/Write where the object contains customer data or PII ⚡ critical
- Review Criteria-Based Sharing Rules — confirm each rule still matches a current business use case
- Audit Owner-Based Sharing Rules — flag rules that grant access based on user names or IDs rather than roles/groups
- Check for sharing rules that grant "Public Read/Write" access — this is almost never the right setting for data-sensitive objects
- Review the Role Hierarchy — confirm it reflects the actual reporting structure and no level is skipped in a way that grants unexpected access
- Check for manual sharing — look for records shared manually to users outside the role hierarchy (Run as: Your Name, Setup → Sharing Settings → Manual Sharing)
- Verify that the High Volume Portal User OWD setting is appropriate if you have partner or customer portals
- Review Territory Management sharing if Enterprise Territory Management is enabled — territory hierarchies add a parallel sharing dimension
The "just set it to Public Read/Write to unblock the team" problem
Admins set OWD to Public Read/Write as a workaround when a sharing rule is too complex or when a new integration needs broad access. It's fast. It's also a permanent hole. Every subsequent permission and sharing rule has to fight against that default.
If you find OWDs set to Public Read/Write on sensitive objects, change them now — to Private or Public Read Only — and add a proper criteria-based sharing rule instead. It's more work upfront, but it gives you an audit trail and control.
4. API Access & OAuth Connected Apps
OAuth-connected apps are the most overlooked attack surface in Salesforce security audits. They authenticate with a user's session and inherit whatever that user's permissions include. A connected app installed by a departed contractor in 2022 may still have active refresh tokens and access to your org's data.
OAuth & API Access 9 items
- Export all Connected Apps — note which ones are active, which users authorized them, and when they were last used
- Flag Connected Apps with no active API usage in the last 90 days — revoke unused tokens ⚠ warning
- Audit Connected App policies — check which permission sets are required, which OAuth scopes are granted, and whether the app is allowed to act on behalf of any user
- Review all Connected Apps for "Refresh Token" scope — this means the app can re-authenticate indefinitely without user interaction
- Check for Connected Apps installed by users who are no longer in the org — audit the "Installed By" field
- Verify that all API-only integrations (server-to-server, no UI) use JWT-based auth or connected app policies rather than username-password flows
- Audit session settings for API access: check "Require IP range for API access" — this prevents tokens stolen elsewhere from being used
- Review the Connected App "Permitted Users" policy — set to "Admin approved users are pre-authorized" unless the app genuinely needs org-wide access
- Check for any active Named Credentials using username-password auth — these credentials are stored in Salesforce and if the user account is compromised, the credential is exposed
5. Field-Level Security & Sensitive Data
Field-level security (FLS) controls which users can see and edit specific fields — including encrypted fields, custom fields containing PII, and standard fields that expose sensitive data in list views and reports.
Field-Level Security 6 items
- Identify all custom fields containing PII (email addresses, phone numbers, dates of birth, national IDs, financial account numbers)
- Confirm FLS is set to Read-Only or Hidden for non-admin users on every PII field — if FLS is not set, any user with Read on the object can see the field
- Review Field-Level Security on encrypted custom fields (Certificate Management or Shield Platform Encryption) — encryption doesn't protect against users with Read All access
- Check for fields with Edit access granted to users who shouldn't be able to modify historical data (e.g., LastModifiedDate, CreatedDate)
- Audit page layouts — remove sensitive fields from page layouts for non-admin users even if FLS allows Read, especially in list views and related lists where data is shown by default
- Review custom fields with API names containing "ssn", "dob", "account_number", "password", "token" — confirm FLS is set appropriately
6. Audit Trail & Monitoring Configuration
Audit logs tell you what happened. Monitoring configuration determines whether you get alerted when something bad happens. Both are required for an effective security posture — and both are often overlooked until after an incident.
Monitoring & Logging 6 items
- Verify that Setup Audit Trail is enabled — it records configuration changes and is retained for 6 months by default
- Confirm Event Monitoring is enabled if your org has Salesforce Shield — EventLogFile records login events, API calls, and report exports
- Set up Login History alerts for logins from unrecognized IP ranges (Setup → Login IP Ranges)
- Check that the "Login Forensics" or equivalent SIEM integration is running if your org has a security information and event management system
- Verify that field history tracking is enabled on sensitive custom objects — this creates a permanent record of who changed what and when
- Review the "Monitor Login As" setting — ensure that any admin using "Login As" for a user account triggers a log entry that you review regularly
See Your Org's Security Posture in One View
The Org Health dashboard surfaces dormant accounts, permission bloat, sharing rule gaps, and OAuth risk — in a single scorecard, updated on demand.
How to Run This Audit in Practice
Don't try to work through all 47 items in one sitting. Break the audit into five focused sessions, one per section above. Each session takes 30–60 minutes. Covering one section per week for five weeks is more effective than a marathon audit that gets abandoned halfway through.
Before you start
Export everything you need before making changes. An audit that finds problems you then can't fix because you didn't capture the baseline is a common failure mode. Before touching anything, export:
- User list with Last Login, Profile, Role, and Permission Set assignments
- Permission Set list with creation date, last-modified date, and assignment count
- Org-Wide Default settings for all custom objects
- Connected App list with install date and authorized users
- Sharing Rules (criteria-based and owner-based)
Keep these exports in a shared security folder with a quarterly retention policy. Each audit cycle, compare against the previous export to see what's changed. That delta — what's new, what's been modified, what's been removed — is the actual audit surface.
What to fix first
If you're working through this with limited time, prioritize in this order:
- System Administrator accounts — if your admin account is compromised, everything else is irrelevant. Lock it down first: IP ranges, two-factor, no shared credentials.
- Dormant Active accounts — deactivate anything that hasn't logged in since last quarter. You can reactivate it when needed.
- OAuth Connected Apps with unused tokens — revoke access for anything that hasn't made an API call in 90 days. Your integrations will break if you miss one, but the risk of leaving live tokens unused is higher.
- OWD on sensitive custom objects — if your customer data object is Public Read/Write, nothing else matters. Fix that next.
- Permission sets with Modify All — identify which permission sets grant Modify All on sensitive objects and audit who has them.
After the first pass, set a quarterly reminder. Security posture decays — a clean audit in July will have new issues by October.
Security audits and AI agent adoption
As Salesforce orgs adopt Agentforce and Einstein AI features, the security surface expands. AI agents operate within the permission context of the user account they act on behalf of. If that account has an orphaned permission set that grants access to sensitive objects, the AI agent inherits that access — and you may not know it's being used.
Cleaning up permission sets and OAuth apps before enabling AI features is not optional in 2026. It's prerequisite work.