How to run a Salesforce security review: a 14-point checklist

Salesforce’s built-in Health Check produces a percentage. It is a genuinely useful number and it covers a narrow slice: password policies, session settings, certificate configuration. An org can score 90% and still have a guest user who can read every Contact.

A real review covers fourteen areas. You can work through them manually in Setup — this is the list to work through.

Access and identity

1. Org baseline. Start with the Health Check score and org-wide settings — but treat it as one input, not the answer. Note the edition, the API version floor, and whether the org has been through an acquisition or a migration.
2. Authentication and SSO. Is MFA actually enforced, and where? If SSO handles it at the identity provider, Salesforce’s own settings will look permissive while the org is fine — you have to verify at the IdP, not just in Setup. Check login IP ranges, login hours, and whether API-only users bypass the lot.
3. Users and licences. Active users who have not logged in for 90 days are the cheapest risk reduction available. Look for shared accounts, integration users with interactive login enabled, and frozen-but-not-deactivated accounts.
4. Privileged access. The one that matters most. Who holds Modify All Data, View All Data, Author Apex, and Manage Users — via profile, permission set, and permission set group. The number is almost always higher than the admin expects, because permission set groups hide it.

Data exposure

5. Permission hygiene. Permission sets with zero assignments, sets that duplicate each other, and profiles still carrying permissions that should have moved to sets years ago.
6. Object and field-level security. Which profiles can read or edit sensitive fields. Pay attention to fields carrying a Data Sensitivity Level or Compliance Categorization — and to the ones that should carry them and don’t.
7. Sharing model. Org-wide defaults, sharing rules that widen them, and manual shares. A public-read-write OWD on an object holding regulated data is worth finding before an auditor does.
8. Guest and external users. Experience Cloud guest profiles, sharing sets, and guest-accessible Apex. This is where the well-known Salesforce data exposures have come from.
9. Files and egress. Who can export reports, who has Data Export scheduled, and what content is shared via public links.

Code, automation and integrations

10. Apex security. Classes running without sharing, SOQL built by string concatenation, and @AuraEnabled methods that skip isAccessible() checks. An @AuraEnabled method with no permission check is directly callable by any authenticated user.
11. Automation and flows. Flows running in system context that write to objects the invoking user cannot see. Screen flows exposed to guest users.
12. Integrations and auth. Connected Apps and their OAuth scopes, named credentials, remote site settings, and auth providers. Look for apps nobody remembers installing and scopes far wider than the integration needs.
13. Monitoring and audit. Is Setup Audit Trail being exported before its retention window closes? Is Event Monitoring available and actually used? Login forensics?
14. Packages and platform. Installed managed packages, their permission footprint, and whether any are unsupported or abandoned.

Doing it without a fortnight of clicking

Manually, this is genuinely a week of Setup archaeology, and the result is a spreadsheet that is out of date by the time you present it. The parts that are deterministic — who holds which permission, which users are stale, which OWDs are open, which classes run without sharing — are all queryable.

orgadmin.ai’s Security Review runs exactly these fourteen modules: the deterministic checks execute as queries, and the judgement calls — what does this combination of permissions actually expose? — are analysed with AI against the collected evidence. Findings come out with a severity, the evidence behind them, and a triage state, so you can mark something accepted-risk and not see it again next run.

Whatever you use, the discipline is the same: cover all fourteen areas, record why you accepted the risks you accepted, and re-run it after any significant org change.