Salesforce security review checklist: access, sharing and audit

A Salesforce security review answers three questions: who can log in, what each person or system can see and change once inside, and whether you could reconstruct what happened after the fact. In practice that means checking MFA and login settings, how permissions are granted through profiles, permission sets and permission set groups, the sharing model, integration users and connected apps, field-level security on sensitive data, and the audit tools you have. Most findings are over-granted access that nobody removed.

Authentication: MFA and login controls

Salesforce now enforces multi-factor authentication for direct logins to its orgs, and during 2026 it has rolled out a requirement for phishing-resistant methods, such as passkeys, built-in device authenticators and security keys, for admins and other privileged users. The permission that used to exempt users from MFA no longer does so on its own; a genuine exemption, such as an automated testing tool, now goes through Salesforce Support. A review should confirm:

• Every person who logs in directly is enrolled in MFA, and admins use a phishing-resistant method.
• Anyone signing in through single sign-on is covered by MFA at your identity provider.
• Login IP ranges or login hours are set on profiles where the business can support them.
• Session timeout and session security settings match your policy, not the defaults.
• Setup > Health Check shows no high-risk settings against the Salesforce Baseline Standard, or a custom baseline you have chosen.

Health Check is quick and free, and it is the right place to start. It only grades org-level settings, though, so a good score says nothing about whether the wrong people hold powerful permissions.

Profiles, permission sets and permission set groups

Salesforce had planned to retire permissions on profiles, then cancelled that retirement after customer feedback. Profiles still work, but Salesforce recommends a permission set–led model: give users a minimal base profile, such as Minimum Access – Salesforce or a clone of it, keep settings like page layouts, login hours and IP ranges there, and grant object, field and user permissions through permission sets bundled into permission set groups. A group can also mute a permission its users should not have, without editing the sets underneath.

Whatever model the org uses today, search for these permissions and justify every user who holds them: Modify All Data, View All Data, Customize Application, Manage Users, Author Apex, Export Reports and API Enabled. Check object-level View All and Modify All too, since they bypass the sharing model for that object. A clone of System Administrator given to a sales manager years ago is one of the most common findings in any org.

The sharing model

Record access is layered: organization-wide defaults set the baseline for each object, the role hierarchy opens records upward, and sharing rules, teams and manual shares open them sideways. Review the defaults object by object and ask whether each one is Private, Public Read Only or Public Read/Write on purpose. Then check that the role hierarchy mirrors who genuinely needs to see whose data, rather than the org chart.

Regulated firms feel this most. For a broker-dealer supporting 140+ associated persons, we built three contact record types, for issuers, investors and associated persons, with role-based security controlling who sees each. If the org has an Experience Cloud site, review external sharing and guest user access separately; a payment-processing company we worked with runs a portal for 60+ agents, and portals of that size make external sharing rules a first-class item in the review.

Integration users and connected apps

Every integration should run as its own user, never as an employee's login. Salesforce offers a Salesforce Integration user license with the Minimum Access – API Only Integrations profile, which restricts the user to API access; add permission sets to grant only the objects and fields that integration touches. List each integration user with its owner, purpose and the system on the other end.

Connected apps deserve their own pass. Since September 2025, Salesforce has restricted uninstalled connected apps, so most users can no longer authorize them unless they already did, or hold a permission such as Approve Uninstalled Connected Apps or, with API Access Control on, Use Any API Client. Review the connected apps OAuth usage list in Setup, install and restrict the apps you trust, revoke the ones nobody can explain, and limit who holds those bypass permissions.

Field-level security on sensitive data

List the fields that carry sensitive data: tax IDs, dates of birth, bank details, health information, compensation, commission and pricing floors. For each, confirm who can read and edit it through permission sets, not just whether it appears on a page layout. Removing a field from a layout hides it from casual view, but it can still be reached through reports, list views, exports and the API if field-level security allows it.

Apply the same test to automation and AI. A Flow set to run in system context, or an agent running as its own agent user, can read and change records the person who triggered it could never open. Note which user each agent, scheduled Flow and Apex job runs as, and scope that user as tightly as an integration user. Then check who can export: the Export Reports permission and the weekly data export service both move large amounts of data out of Salesforce in a single step.

Audit trail and optional event monitoring

Know what the org can tell you after something goes wrong, and for how long. Most of it is available without extra licensing.

Event Monitoring is optional. It earns its cost when you must investigate data exports, prove who viewed a record, or feed a security team's monitoring tools; many smaller orgs get by with the audit trail, field history and regular reviews. If you rely on the free one-day files, download them daily or they are gone.