Salesforce Security Review Checklist for Admins

What a security review protects you from:

• Data breaches — overly permissive profiles grant access to fields that should be restricted
• Insider risk — former employees or contractors retain active logins or API access
• Compliance failures — HIPAA, GDPR, SOC 2, and industry regulations require demonstrable access controls
• Audit failures — if you can't answer "who has access to this data," you fail the audit
• Unauthorized API access — unreviewed connected apps become a persistent back door

Gather before you start:

• Current user list — export from Setup → Users → Active Users to CSV. Cross-reference against HR records to identify departed employees.
• Active profiles inventory — list every profile in use and the user count assigned to each. Profiles with 0 users are candidates for deletion.
• Permission sets inventory — list every permission set and which users or groups have been assigned each one.
• Connected Apps list — Setup → Apps → Connected Apps → Connected Apps. Note which are OAuth-enabled, which users they're assigned to, and when each was last accessed.
• Previous security review notes — if you've done this before, pull the prior findings. Unresolved issues from past reviews are your highest priority.
• Org-wide defaults documentation — know your current OWD settings for every object before you start, so you can spot accidental changes or configuration drift.
• IP restriction and login policy documentation — current trusted IP ranges, MFA enforcement status, and session timeout settings.

Users

• ☐ Deactivate all users who are no longer active employees or contractors
• ☐ Confirm no shared user accounts exist (each person has their own login)
• ☐ Review users who haven't logged in for 90+ days — these are candidates for deactivation
• ☐ Confirm that all System Administrator users are justified — the list should be short and documented
• ☐ Review users with "Modify All Data" or "View All Data" — flag any that shouldn't have org-wide access

Profiles

• ☐ Audit every non-standard profile — are the permissions still appropriate?
• ☐ Delete or disable profiles with 0 active users (after confirming they're not referenced in automation)
• ☐ Review cloned Standard User or Admin profiles — these often carry excess permissions inherited from the parent
• ☐ Confirm no profile grants "Author Apex" to users who don't write Apex code
• ☐ Confirm no profile grants "Manage Users" to users outside your admin team

Permission Sets

• ☐ Audit every permission set for "why does this exist" — remove sets without a clear documented purpose
• ☐ Review permission set assignments per user — should they all still have these sets?
• ☐ Look for permission sets that duplicate profile permissions — these are often leftover from past projects
• ☐ Check for permission sets granted to users temporarily (for a project or support case) that were never removed

Role Hierarchy

• ☐ Review the role hierarchy — does it reflect the current org structure?
• ☐ Confirm no stale roles are assigned to active users (roles from departments that no longer exist)
• ☐ Check that roles above record owners in the hierarchy actually need visibility to those records

Priority: Sensitive Fields

Start with the fields that carry the most risk if exposed:

• ☐ Social Security Numbers or government ID fields
• ☐ Bank account or payment information fields
• ☐ Personal health information fields (HIPAA orgs)
• ☐ Salary, compensation, or HR fields
• ☐ Authentication credentials stored as custom fields (API keys, passwords — these shouldn't exist)
• ☐ Date of birth, address, or other PII fields subject to GDPR

For each sensitive field: confirm read and edit access is restricted to only the profiles and permission sets that genuinely need it.

FLS Audit Process

• ☐ Setup → Object Manager → [Object] → Fields & Relationships → [Field] → Set Field-Level Security — review for every sensitive field
• ☐ Check both Read Access and Edit Access — users shouldn't have Edit on fields they only need to view
• ☐ Confirm FLS for integration user profiles — API integrations often get overly broad FLS during setup
• ☐ Review FLS on any field added in the last 90 days — new fields often get "Visible to All" defaults that weren't intentional

Org-Wide Defaults

• ☐ Setup → Sharing Settings → Org-Wide Defaults — review every object's default access level
• ☐ Confirm high-sensitivity objects (financial data, health records, HR data) are set to Private, not Public Read or Public Read/Write
• ☐ Flag any object set to Public Read/Write unless you have a documented reason — this gives every user edit access to every record
• ☐ Check "Grant Access Using Hierarchies" — disabled for objects where you explicitly don't want managers seeing subordinates' records

Sharing Rules

• ☐ Review all criteria-based and ownership-based sharing rules — confirm each still applies to current business processes
• ☐ Look for sharing rules created for specific individuals or teams that no longer exist
• ☐ Check sharing rules granting Read/Write vs Read-Only — is write access actually needed?
• ☐ Review manual shares (Setup → Sharing Settings → View All button per object) — these are often forgotten and persist indefinitely

Guest User Sharing (Sites & Communities)

• ☐ If you use Experience Cloud or Sites, audit the Guest User profile — unauthenticated access should be minimal
• ☐ Confirm no sensitive objects have sharing rules that include the Guest User role
• ☐ Check that "Secure guest user record access" is enabled in Sharing Settings

Multi-Factor Authentication (MFA)

• ☐ Setup → Identity → Identity Verification — confirm MFA is enforced, not just available
• ☐ Confirm "MFA for UI Logins" is enabled in Session Settings (Salesforce requires this for compliance)
• ☐ Review which profiles have "Multi-Factor Authentication for User Interface Logins" permission — it should be all of them
• ☐ Confirm API-only users are appropriately scoped and don't require UI MFA (but should still have strong password policies)

Session Settings

• ☐ Setup → Security → Session Settings — review session timeout value (2 hours or less recommended)
• ☐ Confirm "Lock sessions to the IP address from which they originated" is enabled for high-sensitivity orgs
• ☐ Review "Force logout on session timeout" — should be enabled
• ☐ Disable "Enable clickjack protection" only if you have a documented reason (it should be on)

IP Restrictions

• ☐ Setup → Security → Network Access — review trusted IP ranges. Are stale ranges from old office locations or VPN setups still listed?
• ☐ Review Login Hours per profile — confirm restrictions are in place for users who should only access during business hours
• ☐ Review Login IP Ranges per profile — high-privilege profiles (System Admin) should have tighter IP restrictions than standard users

Connected Apps

• ☐ Setup → Apps → Connected Apps → Connected Apps — list every app and identify its business owner
• ☐ Revoke access for any app whose vendor relationship has ended or whose purpose is unclear
• ☐ Confirm OAuth policies per app — "Admin approved users are pre-authorized" is safer than "All users may self-authorize"
• ☐ Review which profiles can access each Connected App — restrict to the minimum needed
• ☐ Check refresh token policies — long-lived tokens on inactive apps are a persistent risk

API-Enabled Profiles

• ☐ Identify every profile with "API Enabled" permission — only profiles actually making API calls need this
• ☐ Dedicated integration users should have dedicated profiles — don't use Standard User or cloned Admin profiles for API access
• ☐ Confirm integration users are not assigned licenses that grant UI login (use Integration or API-only license types where possible)

OAuth Tokens & External Credentials

• ☐ Setup → Identity → OAuth and OpenID Connect Settings — review all OAuth-connected applications
• ☐ Setup → Named Credentials — confirm all named credentials reference active, valid endpoints
• ☐ Review External Credentials and their associated Principal assignments — are these still needed?
• ☐ Look for Apex code or flows that store credentials in custom fields or custom metadata — these should be replaced with Named Credentials

• Security flags — profiles with excessive permissions, inactive users with active logins, API-enabled profiles that shouldn't be
• Permission set analysis — unused sets, over-assigned permissions, duplicates between profiles and sets
• FLS issues — sensitive-looking fields with broad visibility, recently added fields with default open access
• OWD and sharing — objects with overly permissive defaults flagged with severity ratings
• A health score from 0–100 — so you can track security posture over time, not just check boxes once