Salesforce ships with a deep and flexible security model — which is exactly why orgs drift into risk over time. New profiles get cloned, permission sets pile up, an integration user is granted a little too much "just to make it work," and a guest user quietly gains read access to objects it shouldn't see. None of these are dramatic on their own, but together they widen your attack surface.
Here's a practical, high-impact checklist we use as a starting point when assessing a Salesforce org. It won't replace a full assessment, but verifying these ten items will catch the issues we see most often.
Start with org-wide defaults (OWD). The principle is simple: set the most restrictive default that still lets people do their jobs, then open access deliberately with role hierarchy, sharing rules, and manual shares. If an object's OWD is Public Read/Write "for convenience," that's worth challenging.
Profiles should be lean. The real power should live in permission sets and permission set groups, which are easier to assign, audit, and revoke. Look specifically for dangerous system permissions granted too broadly:
Modify All Data and View All DataAuthor Apex and Customize ApplicationManage Users and Assign Permission SetsAPI Enabled on users who never use the APIEach of these is a legitimate permission — the question is whether the people holding it actually need it.
If you run Experience (Community) Cloud, the guest user is one of the most common sources of accidental exposure. Confirm guest-user object and field permissions are minimal, sharing for guest access uses the secure model, and that no Apex classes or flows exposed to guests leak data. This is where we find real problems most often.
Apex runs in system context by default, bypassing the permissions a user would otherwise hit. Secure code explicitly checks object (CRUD) and field-level security (FLS), and uses WITH SECURITY_ENFORCED in SOQL or the Security.stripInaccessible() method where appropriate.
A single Apex controller that returns data without an access check can undo an otherwise careful sharing model.
Every connected app is a door into your org. List them, confirm each is still in use, and tighten OAuth scopes to the minimum required. full and api scopes should be rare and justified. Revoke anything orphaned.
Integration and service accounts tend to accumulate permissions. Give each integration its own dedicated user with a tailored permission set, IP restrictions where possible, and no interactive login rights beyond what the integration needs.
Depending on your edition and licensing, enable: multi-factor authentication (now required), session security and timeout settings, login IP ranges and login hour restrictions for sensitive profiles, and — if you have it — Salesforce Shield for platform encryption and Event Monitoring.
Verify password complexity, expiration, and lockout policies match your risk tolerance, and that session settings enforce HTTPS, reasonable timeouts, and protection against session fixation.
Setup Audit Trail covers configuration changes, but it only retains six months. For real visibility, export it regularly and — if licensed — use Event Monitoring to track logins, report exports, and API activity. You can't hunt for threats in data you aren't collecting.
Security isn't a one-time project. Capture your baseline, assign an owner, and re-run this checklist on a cadence — quarterly is a reasonable default — and after any major release or org change.
If you'd like a second set of eyes, a Salesforce Security Assessment from Echo turns this checklist into a prioritized findings report with concrete, developer-aware remediation steps.