Auditing the security of a Salesforce org: what to check, in order
Order matters. These seven checks are ranked by return: the first reveals the most risk for the least effort, the last demands the most work for the most diffuse gain.
What Health Check does not tell you
The native Health Check scores session and password settings against a
baseline. It looks at neither effective permissions, nor connected apps, nor outbound
integrations, nor code. A Health Check score of 90% is compatible with an integration account
that combines Modify All Data and an API with no MFA.
1. The effective permissions of non-human accounts
Start with them, not with users. An integration account often carries the broadest permissions in the org and the weakest controls: no MFA, no IP address restriction, a password that never expires.
The permission to measure is the effective one — the sum of the profile and of every permission set assigned. Reading the profile alone systematically underestimates.
2. Authentication status, cross-referenced with permissions
The useful question is not “how many accounts without MFA?” but “which accounts without MFA carry broad permissions?”. The cross-reference is what turns a list into a priority.
3. Connected apps and their OAuth scopes
Every authorised app holds a token that outlives the departure of the person who authorised it.
Three questions: which scopes were granted, when the app was last used, and who authorised it.
A dormant app with a full scope is permanent access that nobody is watching.
4. Guest access and communities
The guest profiles of Experience Cloud sites sometimes inherit unintended object permissions. The data exposed is then exposed to an unauthenticated visitor. This check is quick to run and regularly produces surprises.
5. Certificates and outbound communications
An expired certificate does not raise a security alert: it causes an integration outage, on a Friday evening. Record the expiry dates, and the status of outbound endpoints — an endpoint that fails silently is a business flow that no longer runs.
6. Headroom on platform limits
Salesforce limits — API calls per day, storage, concurrent asynchronous jobs, Bulk batches — are consumed gradually. They are only discovered at the ceiling, which is to say at the worst possible moment. The useful measure is the remaining headroom and its trend, not the instantaneous value.
7. Deployed code and configuration drift
The last check is the most expensive to carry out: the quality of the Apex and LWC code running in the org, and the gap between the current configuration and a reference state. The gain is real but diffuse — this is what you look at once the first six checks are under control.
A method, not a campaign
These seven checks share one flaw: their result is out of date the next day. A permission set assigned, a connected app authorised, a certificate approaching its expiry date — each changes the state without triggering anything.
This is why an annual audit mostly measures the moment at which it took place. What protects is repeated measurement and comparison with the previous state.
Do you need a tool to run this audit?
No for the first pass: the seven checks above can be run by hand, given time. Yes for the repetition: it is the frequency, not the depth, that calls for tooling.
What should an actionable audit produce?
An actionable finding names its target — the profile, the app, the certificate — states why it is serious, and proposes a remediation that someone can carry out. A list of scores with no named target does not turn into action.