Salesforce Security Best Practices Every Admin Should Have in Place
Most Salesforce orgs have gaps in their security setup that nobody has reviewed in years. Here is a practical checklist of the settings, permissions, and configurations that protect your data and keep your org audit-ready.
Security is one of those things that feels fine until it is not. Most Salesforce orgs are configured by someone who no longer works there, inherited settings from a previous admin, or have accumulated years of permission creep that nobody has audited. The result is an org that technically functions but is quietly exposed.
This is not about paranoia. It is about having the basics in place so that when something goes wrong — a disgruntled employee, a phishing attack, an accidental mass export — your org is not the reason it became a crisis.
Start With Profiles and Permission Sets
The most common security gap in Salesforce is over-permissioned users. When everyone has System Administrator access "just in case," you have no meaningful security model at all. Start by auditing who has what.
Profiles define the baseline — what objects a user can see, what they can create, edit, or delete. Permission sets layer on top for exceptions. The goal is least-privilege access: every user should have exactly what they need to do their job and nothing more.
Run a report on all active users with System Administrator profiles. If that list is longer than two or three people, you have work to do.
Review Your Login and Session Settings
Salesforce gives you a lot of control over how users authenticate and how long sessions stay active. Most orgs leave these at defaults, which are not always the most secure.
- Multi-factor authentication (MFA): Salesforce now requires MFA for all users. If you have not enforced it, do it now. Go to Setup > Identity > Multi-Factor Authentication.
- Session timeout: Set an appropriate session timeout under Setup > Session Settings. Eight hours is a reasonable default for most orgs; shorter for high-sensitivity environments.
- Login IP ranges: If your team works from known locations, restricting login to specific IP ranges adds a meaningful layer of protection.
- Login hours: For most staff profiles, there is no reason someone should be logging in at 3 AM. Restrict login hours to business hours on non-admin profiles.
Audit Your Sharing Model
Salesforce has a layered sharing model: org-wide defaults, role hierarchy, sharing rules, and manual shares. When this is set up correctly, users see exactly what they should. When it is not, you end up with either too much visibility or too little.
Check your org-wide defaults under Setup > Sharing Settings. For most objects, "Private" is the most secure starting point — users only see records they own. You then open access up deliberately through the role hierarchy and sharing rules.
If your org-wide defaults are set to "Public Read/Write" on sensitive objects like Contacts or Opportunities, that is worth revisiting. Anyone in the org can edit anyone else's records, which creates both a data integrity and a compliance risk.
Check Your Connected Apps and API Access
Every third-party tool connected to your Salesforce org is a potential attack surface. Go to Setup > Connected Apps and review what is there. You will often find apps from vendors you no longer use, integrations set up by consultants who are long gone, and OAuth tokens that have never been rotated.
For each connected app, ask: Is this still in use? Does it need the level of access it has? Is it using a named credential or a shared service account? Revoke access for anything that is no longer active.
Also review your API-only users. These are accounts used by integrations to connect to Salesforce. They should have the minimum permissions needed, should not be able to log in via the UI, and should be reviewed any time a vendor relationship ends.
Enable and Review the Security Health Check
Salesforce has a built-in tool for this: the Security Health Check, found under Setup > Security > Health Check. It scores your org against Salesforce's baseline security standards and flags specific settings that fall below the recommended threshold.
A score of 100 is not always realistic or necessary, but anything below 70 usually indicates meaningful gaps. Work through the flagged items in order of risk — password policies, session settings, and network access restrictions are typically the highest-impact fixes.
Run the Health Check quarterly. Settings drift over time as new users are added, integrations are configured, and profiles are modified. A quarterly review catches issues before they become incidents.
Do Not Forget Field-Level Security
Object-level security controls who can see a record. Field-level security controls who can see specific data within that record. These are different, and both matter.
Sensitive fields — Social Security numbers, bank account information, health data, salary figures — should be restricted at the field level so that only the profiles that genuinely need them can see them. This is especially important for nonprofits handling donor financial data or healthcare organizations with patient information.
Review field-level security on your most sensitive objects at least once a year. It is tedious work, but it is the kind of gap that shows up in compliance audits and data breach investigations.
Deactivate Former Employees Immediately
This sounds obvious, but it is one of the most common security failures in practice. When someone leaves the organization, their Salesforce account needs to be deactivated the same day — not when IT gets around to it, not after their last paycheck clears.
Build a formal offboarding checklist that includes Salesforce deactivation. If your org uses single sign-on (SSO), deactivating the identity provider account may not automatically deactivate Salesforce — verify your setup and close both doors.
The Bottom Line
Salesforce security is not a one-time project. It is an ongoing practice. The orgs that stay secure are the ones that treat security reviews as a regular part of administration, not something that only happens after an incident.
If your org has not had a security review in the past year, start with the Health Check and the user permission audit. Those two steps alone will surface the most common gaps and give you a clear picture of where to focus.
Related Services
John Holloway
4x Salesforce Certified | 11+ Years Experience | Founder, Holloway Tech Consulting
LinkedIn Post Copy
Just published a new article on my site: "Salesforce Security Best Practices Every Admin Should Have in Place" Most Salesforce orgs have gaps in their security setup that nobody has reviewed in years. Here is a practical checklist of the settings, permissions, and configurations that protect your data and keep your org audit-ready. Read the full post: https://hollowaytechconsulting.com/blog/salesforce-security-best-practices #Salesforce #SalesforceAdmin #CRMSecurity #DataProtection #SalesforceConsulting
Is Your Salesforce Org Secure?
Get a free org assessment and find out where your security gaps are before they become a problem.
Book a Free Consultation