Salesforce Security Audit Checklist — 47 Items, 7 Categories

Start with identity — before anything else. Who can log in, how they authenticate, and whether their access is current and intentional.

• #1
  Active users that have never logged in

  WhyAn Active user record with no login history was likely created for a future hire that never arrived, or by a bot. Either way, it is a valid credential that nobody is watching.

  VerifySetup → Users → Company Users; filter Active = true; inspect the Last Login column for empty values.
• #2
  Active users not logged in for 90+ days

  WhyA dormant credential is an attacker-ready backdoor. It will not trigger an unusual-login alert because the account is in a normal quiet state.

  VerifySetup → Users → Company Users; export to CSV; sort by Last Login; flag rows older than 90 days that remain Active.
• #3
  System Administrator profile assignees

  WhyA compromised System Administrator account is a full org takeover. The number of admins — and the names behind them — should be auditable.

  VerifySetup → Profiles → System Administrator → Manage Users; confirm every assignee is a current named individual.
• #4
  Two-factor authentication enforcement

  WhyPasswords alone are an inadequate control for any user with API access or admin permissions. MFA is the single highest-ROI control for credential theft.

  VerifySetup → Identity Verification; confirm Two-Factor Authentication for User Interface Logins is required for the admin profile and any session-level login.
• #5
  Users with both "API Enabled" and "Modify All Data"

  WhyThis combined permission is the Salesforce equivalent of a root database key — programmatic read and write across every object.

  VerifySetup → Profiles / Permission Sets; cross-check users that have both permissions active in their effective access.
• #6
  Service accounts without a documented owner

  WhyAPI-only service accounts have no human watching them. When a credential leaks, nobody gets paged because nobody owns the rotation calendar.

  VerifySetup → Users; filter by Profile or Permission Set with API Enabled; confirm each row has an assigned owner and a last-rotated date.
• #7
  Inactive users staged for offboarding

  WhyInactive users keep their historical record but lose access. If you cannot confirm an offboarding, you cannot confirm the access has actually been disabled.

  VerifySetup → Users; filter Inactive; cross-reference against your HR offboarding log or HRIS termination report.

Connected apps authenticate as users and keep working long after those users leave. Treat them as live credentials with their own audit rhythm.

• #8
  Connected Apps with no API usage in 90+ days

  WhyA stale connected app is a valid token sitting in a config file or a developer's laptop. It still has access to your org's data.

  VerifySetup → App Manager → Installed Packages; sort by Last Used; flag rows with empty values or older than 90 days.
• #9
  Refresh-token policy has an expiry

  WhyWithout a refresh-token expiry, a connected app's session is effectively permanent. Compromise the authorized user once and you have indefinite access.

  VerifySetup → App Manager → Edit Policies → Refresh Token Policy; confirm Refresh token expires after is set to a finite value (e.g. 90 days).
• #10
  Connected Apps installed by departed users

  WhyOffboarding usually disables the user. It rarely revokes the OAuth tokens the user authorized. Those tokens continue to authenticate using the app's grant.

  VerifySetup → App Manager; review the Installed By field; cross-reference against the offboarding log.
• #11
  Connected App "Permitted Users" policy is restrictive

  Why"All users may self-authorize" means anyone in the org can install the app and hand it refresh tokens. That is rarely what you want for sensitive integrations.

  VerifySetup → App Manager → Edit → Permitted Users; confirm policy is Admin approved users are pre-authorized unless the app genuinely needs org-wide access.
• #12
  OAuth scopes audited for least privilege

  WhyA connected app that requests full and refresh_token scopes has the broadest possible access. Scopes should match what the integration actually needs.

  VerifySetup → App Manager → Edit → OAuth Scopes; flag apps requesting Full, Refresh Token, or Offline Access without a documented business reason.
• #13
  Named Credentials do not use username–password auth

  WhyUsername-password auth stores credentials inside Salesforce. If the integrated user account is compromised, the credential is exposed.

  VerifySetup → Named Credentials; review each row; flag any row whose Auth Protocol is Password Authentication.
• #14
  API-only auth uses JWT or connected app policies

  WhyServer-to-server integrations should authenticate as themselves, not as a user. JWT-based auth has no credential to steal.

  VerifySetup → App Manager; confirm any app that runs server-to-server uses JWT Bearer flow rather than the username-password OAuth flow.

Org-wide defaults set the baseline. Every subsequent sharing rule has to fight against the default. Get the default right and the rest of the model is simpler.

• #15
  No custom object has OWD set to Public Read/Write

  WhyPublic Read/Write on a customer object is a silent, permanent data exposure. Workarounds get set during incident firefighting and rarely get unwound.

  VerifySetup → Sharing Settings → Org-Wide Defaults; locate every row whose Default External Access = Public Read/Write; confirm none of them hold PII or customer financial data.
• #16
  OWD is tighter than required where possible

  WhyPrivate is the safest default. Public Read Only only when there's a real read-only business need. Public Read Write only as a last resort.

  VerifyIn Setup → Sharing Settings, audit each object's Internal Access. For sensitive objects, confirm it is Private.
• #17
  Criteria-Based Sharing Rules reference live record types

  WhyA sharing rule whose record type or picklist value has been retired still grants access to matching records — but no one can update the rule from the UI without errors.

  VerifySetup → Sharing Settings → [Object] Sharing Rules; open the rule; verify the criteria fields and values still resolve.
• #18
  Manual Sharing grants reviewed

  WhyManual sharing bypasses the role hierarchy. A record shared to a specific user remains visible until that share is manually revoked, often years later.

  VerifyRun a report on AccountShare, OpportunityShare, ContactShare; filter where RowCause = Manual; review the grantor and recipient of each.
• #19
  Role Hierarchy reflects actual reporting structure

  WhyA wrong role assignment lets a manager see records their reports should not be able to share upward — and a missing role in the hierarchy creates a sharing gap.

  VerifySetup → Roles; walk the hierarchy top-down; confirm each role's parent matches the actual org chart.
• #20
  External OWD is Private

  WhyExternal OWD determines what portal and Experience Cloud users can see. A Public setting here exposes data to anyone on a customer portal.

  VerifySetup → Sharing Settings → External OWD; confirm the external access column is Private for any object containing customer PII.
• #21
  Field-Level Security protects PII custom fields

  WhyWithout FLS, any user with Read on the object can see every field — including the SSN, DOB, and account number columns.

  VerifySetup → Object Manager → Fields & Relationships; open each PII field; click Set Field-Level Security; confirm non-admin profiles are Read-Only or Hidden.

Network controls are how you stop a stolen credential from being used anywhere in the world. Lock the perimeter to the IPs you actually log in from.

• #22
  Login IP Ranges set on the System Administrator profile

  WhyWithout an IP range, an admin credential works from any IP on the public Internet. With one, it works only from your office or VPN.

  VerifySetup → Profiles → System Administrator → Login IP Ranges; confirm at least one IP range is set and that it covers the actual admin work locations.
• #23
  Trusted IP Ranges configured for API access

  WhyTrusted IP ranges don't block API calls; they decide whether session policy applies. Without them, API sessions of stolen tokens have no IP anchor.

  VerifySetup → Session Settings → Trusted IP Ranges; confirm a tight CIDR list covering your integration endpoints and offices.
• #24
  Password policies meet minimum strength bar

  WhyShort, low-complexity passwords are guessable and replayable. The default 8-character policy is no longer sufficient in 2026.

  VerifySetup → Password Policies; confirm at least 12-character minimum, complexity required, and password history prevents reuse.
• #25
  Session timeout aligned with business hours

  WhyA 2-hour timeout on a finance team's shared workstation protects against walk-away access. A 2-hour timeout on a 24/7 integration is unrealistic. Different profiles may need different timeouts.

  VerifySetup → Profiles → [Profile] → Session Settings; review timeout values per profile; confirm they match the actual work pattern.
• #26
  Lock sessions to domain is enabled

  WhySession-pinning to a domain prevents the session cookie from being used if the user is tricked into logging into a lookalike domain.

  VerifySetup → Session Settings → Lock sessions to the domain; confirm this is enabled.
• #27
  CORS allowlist is minimal

  WhyA CORS allowlist that includes * or stale development origins gives any browser-based attacker a path to invoke Salesforce APIs from a page they control.

  VerifySetup → CORS; review each entry; remove any whitelist range covering all origins and any origin your team no longer uses.

Audit logs tell you what happened. Monitoring configuration decides whether you get alerted before the incident is over. Both are required.

• #28
  Setup Audit Trail is being reviewed

  WhySetup changes are retained for 6 months by default. If nobody is reading them, an attacker who knows the org can quietly reconfigure access.

  VerifySetup → View Setup Audit Trail; confirm a recent weekly or monthly review by a named admin; export the trail to a longer-retention archive.
• #29
  Event Monitoring is enabled on Shield

  WhyEventLogFile records login events, API calls, and report exports. With Shield, it is the difference between knowing something happened and being told about it.

  VerifySetup → Event Monitoring; confirm the feature is licensed and at least one EventLogFile stream is exporting to your SIEM.
• #30
  Field History Tracking on sensitive objects

  WhyField history is the only built-in audit trail for record-level changes. Without it, you cannot answer "who changed this customer's email last Tuesday."

  VerifySetup → Object Manager → Fields & Relationships → Set History Tracking; confirm sensitive objects have at least 20 fields tracked.
• #31
  Login from unrecognized IPs triggers a review

  WhyA login from a country where the user does not work is the single clearest indicator of credential compromise. It only helps if it actually gets reviewed.

  VerifySetup → View Login History; confirm an alert or scheduled review triggers when a login IP falls outside Login IP Ranges.
• #32
  "Login As" activity is logged and reviewed

  WhyAdmins using "Login As" to impersonate a user should leave a trail. The trail should be reviewed because impersonation is also a known lateral-movement technique.

  VerifyIn Login History, filter LoginType = 4 (Login-As); confirm a periodic review covers rows from this filter.
• #33
  Apex exception emails go to a watched inbox

  WhyUncaught Apex exceptions are the most common way unattributed data corruption surfaces. They should reach someone who can act on them within the hour.

  VerifySetup → Apex Exception Email; confirm the recipient list includes a monitored mail group, not a personal inbox that may not be staffed.

Backup posture is rarely the cause of an incident. It is the difference between an incident and a catastrophe. Audit it like the rest.

• #34
  Data Export Service scheduled at least weekly

  WhySalesforce commits to durability, not recoverability of any recent point-in-time. Weekly exports give you a snapshot to roll back to.

  VerifySetup → Data Export; confirm Export Now runs and a recurring schedule exists; confirm the download URL is captured into your backup pipeline.
• #35
  Backup and Restore feature enabled

  WhyBackup and Restore is the only Salesforce native option that gives point-in-time record recovery without a full extraction pipeline.

  VerifySetup → Data Management → Backup and Restore; confirm the feature is licensed and the weekly backup window is enabled.
• #36
  Third-party backup solution if data is regulated

  WhyNative backup is convenient but limited. For HIPAA, PCI, or other regulated data, a third-party backup is typically required for compliance attestations.

  VerifyConfirm a vendor such as OwnBackup, Druva, or equivalent is configured; review the most recent run log and the recovery drill result.
• #37
  Sandbox refresh policy is documented

  WhyAn undocumented refresh cadence leads to sandboxes drifting from production metadata. A clean sandbox is required for safe change deployment.

  VerifySetup → Sandboxes; confirm each sandbox's Refresh Interval and most recent refresh date; confirm the policy is documented in your release runbook.
• #38
  Recycle Bin retention reviewed

  WhyRecords deleted by mistake are recoverable for 15 days through the Recycle Bin and up to an additional 60 days with Salesforce support. Confirm your tier is the longer one if needed.

  VerifySetup → Data Management; review Recycle Bin policy; confirm any records needing longer retention are extracted via Data Loader before they age out.
• #39
  Audit trail of destructive admin actions

  WhyRecord deletion, hard delete, and field deletion are reversible only within a narrow window. Knowing who did it and when is operational.

  VerifySetup → View Setup Audit Trail; filter for Delete actions on records and objects; confirm the trail is reviewed in your weekly security digest.

The day-to-day administrative debris that compounds over years. Permission sets you forgot about. Flows from a 2022 project. Easy wins if you tackle them quarterly.

• #40
  Permission Sets inventoried and dated

  WhyA permission set created in 2023 and never modified is a fossil. Either it's still doing its job (in which case the assignment list should be short and current) or it isn't (in which case it should be retired).

  VerifySetup → Permission Sets; export the list; sort by Last Modified Date; flag sets older than 24 months with low assignment counts.
• #41
  Custom Profiles each have an owner

  WhyProfiles accumulate without anyone assigned to maintain them. The owner field is the only built-in way to make assignment explicit.

  VerifySetup → Profiles; filter to Custom Profiles; confirm each has a documented owner in your internal admin registry.
• #42
  Flows on sensitive objects run with "with sharing"

  WhyA Flow that runs in system context bypasses record-sharing. On customer-sensitive objects, that's how data leaks through automation.

  VerifySetup → Process Automation → Flows; review each Flow whose object is Account, Contact, or Opportunity; confirm Run In Mode is set to User rather than System.
• #43
  Validation Rules on critical objects are documented

  WhyValidation rules built to fix one record in 2021 often remain in place. Without documentation, the next admin treats them as load-bearing and avoids touching them.

  VerifySetup → Object Manager → Validation Rules; export per object; confirm each rule has a documented business owner.
• #44
  Lightning Pages with embedded components reviewed

  WhyA Lightning Page can embed inline code, embedded apps, or external URLs that bypass sharing. Components added to a page in a hurry are rarely reviewed.

  VerifySetup → Lightning App Builder; review pages for sensitive objects; flag any page that contains an HTML iframe, External Services, or a Visualforce component.
• #45
  Static Resources do not contain secrets

  WhyStatic Resources are world-readable by anyone with Read on the object. A hard-coded API key bundled into JavaScript is exposed the moment the JS loads.

  VerifySetup → Static Resources; review each resource's file content; flag any JS, JSON, or ZIP whose unzipped contents include keys, tokens, or passwords.
• #46
  Email-to-Case inbound addresses whitelisted

  WhyAn open inbound Email-to-Case address lets anyone mail the org to create cases. Whitelisting senders guarantees only allowlisted origins can create support traffic.

  VerifySetup → Email-to-Case → Configure; confirm Enable Email-to-Case is on with a whitelisted sender list; flag any open inbound address.
• #47
  Apex classes enforce sharing

  WhyAn Apex class without with sharing runs as system, ignoring the user's record-level access. This is the canonical Salesforce security bug — and it is still common in mature orgs.

  VerifySetup → Apex Classes; confirm classes that touch Account, Contact, Opportunity, or any custom object with PII are declared public with sharing.