The Salesforce Health Check score explained: how it is calculated and what moves it

The Salesforce Health Check score is the one security number most admins can quote from memory. It shows up in status reports, audit questionnaires and quarterly reviews, often without anyone asking what produced it. This post explains how the score is built, why two orgs with identical settings can show different scores, which changes raise it quickly, and where its edges are. For the broader question of what a full security audit adds on top of Health Check, see our post on Health Check vs a security audit; this one stays with the number itself.

#What the score measures

Health Check, in Setup, compares a list of org-wide security settings with a baseline and reports a score from 0 to 100, where 100 means every setting meets the baseline. Salesforce's Trailhead unit on Health Check describes it as a measure of how closely your settings match the recommended values.

The settings are grouped by area: password policies, session settings, network access, login and certificate settings, and similar org configuration. For each setting, Health Check shows your value next to the baseline's standard value and whether you meet it.

#How the score is calculated

Salesforce describes the calculation as a proprietary formula, so you will not find the exact weights published. What is documented is the structure:

• Every setting in the baseline belongs to a risk category: High-Risk, Medium-Risk, Low-Risk or Informational.
• A setting that meets the baseline counts in your favour. A setting that misses it counts against you.
• High-Risk settings carry the most weight, Low-Risk the least, and Medium-Risk sits in between.
• Informational settings are shown for context but do not affect the score at all.

Two consequences follow. First, one missed High-Risk setting can cost more than several missed Low-Risk ones, so the number of red rows is a poor guide to the score. Second, fixing an Informational item makes the page look tidier and leaves the score unchanged.

You can read the same data programmatically through the Tooling API, which is useful for tracking the score over time across several orgs:

sf data query --use-tooling-api --target-org prod \
  --query "SELECT Score FROM SecurityHealthCheck"

sf data query --use-tooling-api --target-org prod \
  --query "SELECT RiskType, SettingGroup, Setting, OrgValue, StandardValue FROM SecurityHealthCheckRisks"

The second query returns one row per setting with its risk type (HIGH_RISK, MEDIUM_RISK, LOW_RISK or INFORMATIONAL), which is enough to rebuild the Health Check page in your own reporting.

#The baseline decides the score

By default Health Check measures against the Salesforce Baseline Standard. You can also import a custom baseline: export the standard as XML, change the values and risk levels to match your own policy, and import it. Trailhead suggests this for regulated industries whose requirements are stricter than the default, and recommends agreeing the baseline with your IT or compliance team first.

This is the part people miss when they compare numbers. The score is always relative to whichever baseline is selected. That means:

• A stricter custom baseline lowers your score without anything in the org changing.
• A looser custom baseline raises it, again with no change to the org.
• Moving a setting from High-Risk to Informational in a custom baseline removes it from the score entirely.
• Salesforce updates its standard baseline over time, so the score can move after a release even if nobody touched Setup.

So "our Health Check score is 92" is only meaningful with "against which baseline?" attached. If an auditor or customer asks for the score, give the baseline name too, and keep the baseline XML under version control so changes to it are reviewed like any other policy change.

#What raises the score quickly

Because High-Risk settings dominate the formula, the fastest gains usually come from a short list:

• Password policies: minimum length, complexity, maximum invalid login attempts and lockout period.
• Session settings: session timeout, clickjack protection, CSRF protection and HTTPS requirements.
• Login and network access: tighter login controls and trusted IP ranges where they fit how people work.

Health Check also offers Fix Risks, which sets the selected settings to the baseline value in one step. Trailhead warns that this can affect integrations or remove user access, and recommends trying changes in a sandbox and making them one at a time. Session settings in particular can break long-running integrations or force users to log in more often than they expect.

The same settings live in source as Security.settings-meta.xml, so a deployment can quietly undo a fix made in Setup. Vulkro for Salesforce checks that file on every scan, with security settings checks such as long-session-timeout, csrf-on-post-off and no-login-attempt-limit, so a regression is caught in the pull request rather than in next quarter's score.

#What the score never measures

Health Check reads org-wide settings. It does not read Apex, Lightning components or Flows, it does not judge your sharing model, it does not inventory guest user access or connected apps, and it does not count who holds Modify All Data. An org can score in the 90s and still expose records to an Experience Cloud guest user. We cover each of these gaps in Health Check vs a security audit; the short version is that the score is a settings hygiene measure, not a measure of who can reach your data.

#Reporting the score alongside everything else

If you want the score in the same report as code and access findings, Vulkro for Salesforce reads it from a live org without changing it:

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

org health-check reports Salesforce's own score and categories unchanged, as one SF-HEALTH-CHECK-001 finding per risk category that has risks. Severity follows the overall score: High below 60, Medium from 60 to 80, Low above 80. The fixes still happen in Setup.

#FAQ

#How is the Salesforce Health Check score calculated?

Salesforce uses a proprietary formula that compares each setting with the selected baseline. Settings are weighted by risk category: High-Risk counts most, then Medium-Risk, then Low-Risk. Informational settings do not affect the score.

#Why did my Health Check score change when nothing changed in Setup?

Either the selected baseline changed (a custom baseline was imported or edited) or Salesforce updated its standard baseline in a release. The score is relative to the baseline, so a different baseline produces a different number for the same settings.

#What is a good Salesforce Health Check score?

Salesforce does not publish a pass mark. Aim to meet every High-Risk setting in the baseline you have agreed with your compliance team, and record that baseline alongside the score so the number means the same thing every time it is reported.

See what else a live-org review covers in Vulkro for Salesforce, or Start a 14-day trial. Related: a read-only Salesforce security audit.