Salesforce Health Check vs a security audit: what each covers

A high Health Check score is often the first thing a Salesforce team shows when someone asks how secure the org is. It is a useful number, but it answers a narrow question: do the org's security settings match a baseline? A Salesforce security audit answers a wider one: who can reach which data, through which code, configuration and integrations, and what would an attacker do with that? This post sets out where Health Check stops, what a real audit adds, and what the audit report should contain.

#What Salesforce Health Check scores

Health Check lives in Setup. It compares a set of org-wide security settings against a baseline and gives you a score out of 100. By default the baseline is the Salesforce Baseline Standard; you can import a custom baseline if your organization has its own standard.

The settings it looks at are org configuration values, for example:

• password policies (length, complexity, expiry, lockout)
• session settings (timeout, clickjack and CSRF protection, session locking)
• login and network access controls
• other org-wide security settings in the baseline

Each setting that misses the baseline is grouped by risk level, and for some of them Health Check offers a one-click fix. It is quick, it is built in, and it is a fair way to catch a weak password policy or a disabled protection.

#What Health Check does not cover

Health Check reads settings. Most Salesforce breaches and audit findings are not settings: they are access paths. None of the following moves the score.

#Custom code

Apex, Lightning Web Components, Aura and Visualforce are out of scope. An Apex class declared without sharing that returns every record to its caller, a SOQL query built from user input, or a controller that skips object and field permission checks will not show up. Neither will a hardcoded credential in a class.

#The sharing model

Organization-wide defaults, sharing rules, role hierarchy and manual shares decide which records each user can see. A Public Read/Write default on a sensitive object, or a criteria-based rule that opens thousands of records to a broad group, is a design decision Health Check does not judge.

#Guest and external access

Experience Cloud sites expose a guest user. What that guest profile can read, which Apex classes and Flows it can invoke, and whether self-registration is open are among the most common sources of real data exposure in Salesforce orgs. Health Check does not inventory them.

#Connected apps and integrations

OAuth scopes, refresh token policies, IP relaxation, unused apps with live tokens, and integration users with broad permissions are outside the baseline. After a stolen-token incident, these are the first things an investigator asks about.

#Permission sprawl

Who holds Modify All Data, View All Data, Author Apex or Manage Users? Which permission sets grant View All on customer objects, and how many active users hold them? Health Check does not count holders or flag dormant administrators.

#Flow running in system context

A Flow set to run in system context without sharing, especially one that a guest can start, can read and write records the running user could never open. That is configuration inside the Flow, not an org setting, so the score stays the same.

#Health Check vs a security audit, side by side

Salesforce also offers Security Center for monitoring posture across many orgs. It widens the view across orgs, but the question it answers is still mostly about configuration and permissions, not your code.

#What a Salesforce security audit report contains

A report that an engineering lead, a CISO and an external auditor can each use has a predictable shape:

1. Scope and method. Which orgs, which metadata and code, which date, what access the auditor had (read-only is normal), and what was not checked. An honest list of gaps matters as much as the findings.
2. Executive summary. The handful of issues that create real exposure, in plain language, with business impact.
3. Findings with evidence. Each finding names the component (class and line, Flow, profile, permission set, app), the severity, why it matters, and how it was established. "Guest user can run this Apex class, which queries Contact without sharing" is a finding. "Review guest access" is not.
4. Access analysis. Who holds the powerful permissions, which integration users are over-privileged, what the guest user can reach.
5. Settings baseline. This is where the Health Check result belongs: one section of the report, not the whole of it.
6. Remediation plan. Fixes ordered by risk and effort, with owners.
7. Re-test. A second run after the fixes, showing what was closed and what is still open.

If you are delivering audits to clients, our post on running a Salesforce security audit as a consultancy covers the engagement itself: access, day-one baseline, executive summary and handover.

#How Vulkro fits

Vulkro for Salesforce covers both halves. It reads the Health Check score from the live org, so the settings baseline is in the same place as everything else:

vulkro-sf org health-check --target-org prod

Then it covers the areas the score does not: the source scan for Apex, LWC, Aura, Visualforce, Flow and metadata, and read-only live org checks for permissions, sharing, guest sites and connected apps.

vulkro-sf scan ./force-app
vulkro-sf org effective-perms --target-org prod
vulkro-sf org sharing-rules --target-org prod
vulkro-sf org guest-live --target-org prod
vulkro-sf org connected-apps --target-org prod
vulkro-sf org report --target-org prod --output org-posture.html

Code findings carry an attack path from the entry point (for example a guest-reachable controller) to the data it touches, with each step cited to a file and line. The org report is a single HTML file you can attach to the audit. Findings are risk signals, and the report never certifies an org clean: that judgement stays with the auditor.

#FAQ

#Is Salesforce Health Check a security audit?

No. Health Check scores org-wide security settings against a baseline. A security audit also reviews custom code, the sharing model, guest access, connected apps, permission assignments and Flows. Health Check is a useful input to an audit, usually one section of the report.

#What is included in a Salesforce security audit report?

Scope and method, an executive summary, findings with evidence (component, severity, reason), an access analysis of powerful permissions and guest exposure, the settings baseline, a prioritized remediation plan, and a re-test showing what was fixed.

#Does a 100% Health Check score mean my org is secure?

It means your org settings match the chosen baseline. It says nothing about whether an Apex class bypasses sharing, a guest user can run a Flow in system context, or an integration user holds Modify All Data.

To see the whole picture for your own org, Start a 14-day trial of Vulkro for Salesforce. Related reading: how Salesforce orgs get breached and what auditors accept from a scanner.