Misconfigured settings are one of the fastest paths to a data breach in a CRM. A weak password policy or a missing clickjack protection setting can expose regulated data and turn into a compliance finding.
Salesforce builds a check for this into Setup: Health Check. It compares your security settings with a baseline, ranks each one by risk, and gives you a score from 0 to 100 that you can track over time.
Configuration drift weakens security with every new user, integration, and release. Health Check gives you a repeatable way to catch drift early and show auditors that your controls still hold, which supports SOX Section 404 reporting on internal control and the GDPR Article 32 requirement for appropriate technical and organizational measures.
The six steps below cover capturing a baseline score, setting your own baseline, auditing access, documenting fixes, adding Health Check gates to your CI/CD pipeline, and tracking scores across orgs.
What is Salesforce Health Check?
Salesforce Health Check is a Setup page that measures how well your org's security settings meet the Salesforce Baseline Standard or a custom baseline you import. It is available in Professional, Enterprise, Performance, Unlimited, and Developer Editions.
Settings fall into four risk categories: High-Risk, Medium-Risk, Low-Risk, and Informational. According to Salesforce's scoring guide, High-Risk settings count the most toward your score, Low-Risk settings count the least, and Informational settings don't count at all.
1. Capture the Baseline Security Score and Prioritize High-Risk Findings
Record where you stand before you change any setting. That snapshot is what you measure every fix, audit conversation, and regression against. Without it, you can't prove improvement or trace a regression later.
From Setup, enter Health Check in the Quick Find box and open the page. Salesforce grades the score in five bands:
- 90% and above: Excellent
- 80% to 89%: Very Good
- 70% to 79%: Good
- 55% to 69%: Poor
- 54% and below: Very Poor
Salesforce recommends remediating high risks immediately if your score is 33% or lower, and fixing high risks in the short term and medium risks in the long term if it falls between 34% and 66%.
Preserve the baseline before you start fixing:
- Screenshot the Health Check page to capture the score and the date
- Export the full list of settings, risk levels, and values with the query below
- Store both files in version control or a read-only location tied to the current release
The SecurityHealthCheckRisks object in the Tooling API returns each setting, its risk category, your org's value, and the standard value. You can export it to CSV with the Salesforce CLI:
sf data query --use-tooling-api \
--query "SELECT SettingGroup, Setting, SettingRiskCategory, RiskType, OrgValue, StandardValue FROM SecurityHealthCheckRisks" \
--target-org prod --result-format csv --output-file healthcheck-baseline.csv
The score itself lives in the SecurityHealthCheck object, which returns a value from 0 to 100:
SELECT Score FROM SecurityHealthCheck
Salesforce Help describes the score as visible on the Health Check page rather than through the API, while the Tooling API reference documents this field, so compare the API value with the page the first time you run the query.
Then fix the High-Risk settings first, because they carry the most weight and close the largest gaps. In the Salesforce Baseline Standard, High-Risk settings include:
- Clickjack protection for Setup pages, non-Setup pages, and Visualforce pages
- CSRF protection on GET and POST requests
- Locking sessions to the domain in which they were first used
- Requiring the HttpOnly attribute
- Maximum invalid login attempts, where 3 is compliant
- Expired certificates
- Objects with default external access set to public
Password policies are Medium-Risk in the baseline. The compliant values are a minimum length of 8 characters, expiration in 90 days or less, a mix of alpha, numeric, and special characters, and at least 3 remembered passwords.
Session timeout is Low-Risk, with 2 hours or less as the compliant value. If your own policy is stricter, you'll set that in step 2.
Health Check doesn't score whether users log in with MFA, so review MFA coverage alongside it.
Hardening controls can break legacy integrations, so test each change in a full sandbox that mirrors your production integrations. Relax IP restrictions on a Connected App only when an integration needs it, and schedule cutovers for low-traffic windows.
For complex environments, roll out fixes in waves: internal users first, then external partners, then system integrations. Record the score after each wave to show progress.
2. Create and Upload a Custom Baseline That Reflects Your Security Standards
The Salesforce Baseline Standard is a general benchmark. If your organization follows stricter internal policies or industry rules, a custom baseline makes Health Check measure against your standard instead. Salesforce's own example is a financial services firm building a baseline from FINRA standards, and you can import up to five custom baselines.
Export and Edit the Baseline File
On the Health Check page, open the Baseline Controls menu and select Export Baseline. Salesforce gives you an XML file with every Health Check setting, its risk category, and the values that count as compliant, warning, or critical.
Edit the file in a plain text editor. You can change values and move settings between risk categories, but you can't add or delete settings. Moving a setting to Informational removes it from the score. The file requirements list the accepted values for each setting, for example:
- PasswordPolicies.minPasswordLength: any whole number from 5 to 50, written with one decimal place, such as "12.0"
- PasswordPolicies.expiration: ThirtyDays, SixtyDays, NinetyDays, SixMonths, OneYear, or Never
- PasswordPolicies.maxLoginAttempts: ThreeAttempts, FiveAttempts, TenAttempts, or NoLimit
- SessionSettings.timeout: FifteenMinutes up to TwentyFourHours
Every value must be in quotation marks, the file must be valid XML no larger than 20 KB, and enum settings must use every accepted value across their compliant, warning, and critical statuses, or the import fails.
Avoid over-tightening. A session timeout that is too short can disrupt mobile users, and stricter login rules can lock out legacy integrations. Write down the business or compliance reason for each change so future admins know why a threshold was chosen.
Test, Import, and Monitor
Validate the custom baseline in a sandbox before you make it the default in production. Check that existing integrations still work, that SSO logins succeed, that mobile access works, and that scheduled jobs aren't blocked.
Expect your score to drop when you tighten a baseline, because more settings now fall short. Use the new score and the list of failing settings to size the remediation work.
To import the file, open Baseline Controls and select Import Baseline. Give the baseline a name and an API name, and optionally make it the default. The CustomBaselineId field on SecurityHealthCheck shows which baseline a score was calculated against, which keeps your pipeline and trend data honest.
Version-control the XML file, link each change to a compliance ticket in the commit message, and review the baseline at least once a quarter so it keeps pace with policy changes.
3. Audit Profiles and Permission Sets for Least-Privilege Access
A high Health Check score doesn't protect your data if users can reach records they don't need. Least privilege means each person gets only the permissions their job requires and nothing more.
Permissions pile up as people change roles or take on temporary projects. Those leftover rights become security gaps that can lead to breaches and compliance findings. Many access problems trace back to old profiles that were never cleaned up or permission sets nobody remembers creating.
Start by finding over-privileged access:
- Filter your Health Check export for access-related settings, such as guest user access and default external access
- Map each finding to the profiles or permission sets that grant it
- In Profiles, search for "View All" and "Modify All" object permissions
- Flag profiles where rights exceed the documented responsibilities
Then clean up legacy assignments, starting with critical roles:
- Remove permission sets that duplicate profile access or were abandoned
- Use Permission Set Groups to bundle related sets
- Assign groups instead of individual sets to simplify audits and reduce accidental over-allocation
Once cleanup is done, set access patterns that stop privilege creep from returning:
- Build lean, department-level profiles as the foundation
- Grant exceptions through additional permission sets, and remove them when the project ends
- Require approval for new permission sets so separation of duties is built into each request
Document each access decision to satisfy auditors and support your wider governance program. Salesforce's Setup Audit Trail records changes to users, roles, permission sets, and profiles with the date and the person who made them, which shortens evidence collection for SOX or GDPR requirements.
Schedule quarterly permission reviews to catch drift. Health Check surfaces misconfigured settings, but only a review confirms that real-world access matches policy. When a review finds drift, fix it in a sandbox, check Health Check again, and promote the change through your normal change controls.
4. Document Every Fix for Audit-Ready Evidence
Auditors want proof that you fixed the problems you found. "We think we fixed that" isn't enough. You need a record of what was wrong, who fixed it, how, when, and how you know it worked. That record turns each settings change into a control you can verify for SOX and GDPR.
Standardize Remediation Logging
Use the same structure for every fix so the log stays searchable across audit cycles. When you're rushing to close gaps, it's tempting to fix first and document later, and that's when details get lost.
For each issue, record:
- What you found: the specific Health Check setting, such as "Maximum invalid login attempts: 10"
- Risk level: High, Medium, or Low
- What you did: the exact change, such as "Set maximum invalid login attempts to 3"
- Who approved it: the person who signed off
- When it happened: the date and time of the change
- Proof it worked: before and after scores, the updated setting value, or test results
Rely on system records over memory or informal notes. Setup Audit Trail logs setup changes, version control tracks metadata changes, and your deployment tool records what moved when.
Setup Audit Trail keeps only the past 180 days, so download it on a schedule and store the files with your other evidence. Change sets move metadata between orgs but don't keep a version history, so if you deploy with change sets, keep a separate record of each release.
Set Up Approval Processes That Auditors Trust
Auditors are skeptical of informal approvals. An email that says "looks good to me" carries little weight. Use a system that records who approved what, and when.
Route every fix to a High-Risk setting through your formal approval path, whether that's a compliance officer, the security team, or a change control board. Make sure the system timestamps each decision and identifies the approver.
Store the evidence somewhere secure and permanent. Regular exports to encrypted storage or your governance system protect audit evidence from accidental deletion. A spreadsheet on someone's laptop is not audit-ready documentation.
Complete records give security and DevOps teams the feedback loop they need to refine processes and show steady improvement, from the first finding to the production change.
5. Embed Health Check Gates in the CI/CD Pipeline
If you only check security settings after a release reaches production, you're documenting problems that already happened. A pipeline gate checks the score at deployment time and stops a release when the target org falls below your standard.
Health Check measures org settings, not the code in a commit. A gate therefore checks the org you are deploying to: run it against a staging or UAT sandbox after deployment, before you promote to production, and against production before and after each release.
Connect Health Check to Your Deployment Pipeline
The SecurityHealthCheck and SecurityHealthCheckRisks objects are Tooling API objects, so your pipeline can query them with the Salesforce CLI. A typical gate works in four steps:
- Authenticate: log in to the org with the JWT flow, using a connected app and a private key
- Check the score: query the current Health Check score
- Decide: compare the score against your minimum threshold
- Block or allow: stop the deployment if the org doesn't meet the standard
The examples use the current sf (v2) commands.
This script logs in, pulls the latest score, and blocks the deployment if it drops below 90:
# --- ci/jobs/healthcheck.sh ---
# 1) Authenticate with the JWT flow
sf org login jwt \
--client-id "$SF_CLIENT_ID" \
--jwt-key-file ./server.key \
--username ci-bot@company.com \
--instance-url https://MyDomainName.my.salesforce.com \
--alias ci-org
# 2) Pull the latest Health Check score (a Tooling API object)
SCORE=$(sf data query --use-tooling-api \
--query "SELECT Score FROM SecurityHealthCheck" \
--target-org ci-org --json | jq -r '.result.records[0].Score')
echo "Health Check score: $SCORE"
# 3) Enforce the gate (change 90 to your threshold)
SCORE_INT=${SCORE%.*}
if [ "$SCORE_INT" -lt 90 ]; then
echo "Score is below the threshold, blocking deployment."
exit 1
fi
echo "Score meets the threshold."
The data query command needs the --use-tooling-api flag to read Tooling API objects. Without it, the query fails.
Configure Threshold Strategy by Environment
Not every environment needs the same threshold. A development sandbox can be more relaxed than production, but you still want to catch problems before they become serious.
- Development and testing environments: Warn when scores drop below your target. Developers get a heads-up without being blocked while they experiment.
- Production: Use a hard stop at 90% or higher. Production holds live data, so don't let a release through if it weakens your security settings.
- Custom security policies: If you imported a custom baseline in step 2, set your pipeline thresholds against that baseline so the gate enforces the same standard.
- Exceptions: Keep a documented list of approved exceptions for releases that lower the score for a legitimate business reason, so the pipeline knows when to let them through.
The overall score can look fine while a single High-Risk setting fails. Add a second check that blocks on any High-Risk setting:
# Count settings that Health Check rates High-Risk
HIGH_RISK_COUNT=$(sf data query --use-tooling-api \
--query "SELECT Setting FROM SecurityHealthCheckRisks WHERE RiskType = 'HIGH_RISK' AND SettingRiskCategory != 'MEETS_STANDARD'" \
--target-org ci-org --json | jq -r '.result.totalSize')
if [ "$HIGH_RISK_COUNT" -gt 0 ]; then
echo "Found $HIGH_RISK_COUNT high-risk settings, blocking deployment."
exit 1
fi
Benefits of Security Gates
A Health Check gate makes security part of the normal release process instead of something you look at after a deployment goes wrong. It is one piece of a wider DevSecOps pipeline.
- Catch problems while they're easy to fix: The team that made the change finds out at release time, not weeks later in a manual audit.
- Build a compliance record: If you store the score from each run, you have a dated history to show auditors instead of recreating what happened.
- Keep environments consistent: The same threshold applies in every org, so you avoid "it worked in my sandbox" surprises in production.
If your pipeline already uses the Salesforce CLI, adding the gate usually means one more job. You can combine it with code scanning to build a quality gate that checks both functionality and security before anything reaches production.
6. Re-Run, Trend, and Scale Across Salesforce Environments
Security drift is gradual. It creeps in as people change settings, add users, and update integrations. Checking Health Check on a schedule helps you spot it before it becomes a vulnerability.
When to Check Health Check
Set a schedule based on when problems are most likely to appear:
- Right after you fix something: Confirm the fix worked before you close the ticket.
- After major releases: New features and integrations can introduce gaps. Check after each major deployment while the changes are fresh.
- Quarterly: Even when nothing major is happening, check every three months to catch slow drift, such as expired certificates or loosened settings.
- When policies change: If your company updates its security requirements, update your custom baseline and check every org.
Keep Track of Your Security History
One score tells you how you're doing today. A history shows patterns and where problems tend to appear. SecurityHealthCheck returns only the current score, so stamp each reading with the date yourself. This job appends one line per run to a history file:
# Append today's score to a history file (one JSON line per run)
sf data query --use-tooling-api \
--query "SELECT Score FROM SecurityHealthCheck" \
--target-org ci-org --json \
| jq -c --arg date "$(date -u +%Y-%m-%d)" \
'{date: $date, score: .result.records[0].Score}' \
>> healthcheck-history.jsonl
Run it from your CI scheduler, for example once a day. After a few months, patterns appear. Scores might dip after every release cycle, or the same session setting might keep failing.
If the line goes flat, check that the job is still running. Your score can also change when Salesforce adds or removes settings from the calculation, so note release dates in your history.
Scale Across Multiple Salesforce Environments
If you manage production, development, and testing orgs, plus regional orgs or subsidiaries, you need the big picture without logging in to each one.
Run the history job against every org and store the results in one place so you can rank orgs by risk and focus where it matters most. Security Center, a paid Salesforce add-on, shows Health Check scores for a parent org and its connected child orgs, including the average score and each org's score.
Keep your standards consistent across orgs. When you update password requirements or roll out MFA to new teams, update the custom baseline in every org so your trend data stays comparable.
As the number of orgs grows, script as much as you can: schedule the score queries, alert when an org drops below its threshold, and feed the history into a shared dashboard.
Turn Health Check Into a Continuous Compliance Framework
Salesforce Health Check turns one-off security reviews into ongoing continuous compliance work. Built into daily operations, it gives you a defensible record that satisfies auditors without slowing development. Health Check covers your org's settings, while Salesforce Trust Center reports on the platform side of the shared responsibility model.
Running it well across many orgs also takes reliable backup and recovery, deployment tooling with approval steps, and audit trails that connect every security change to your release process. Manual processes break down when you manage multiple environments, complex pipelines, and strict compliance requirements.
Flosum DevOps gives Salesforce teams version control, CI/CD pipelines, and release management, so you can add a Health Check gate to each release and trace every change. Flosum Backup & Archive protects the data and metadata behind those changes. You choose where Flosum runs: Salesforce-native, in the Flosum-hosted cloud, or customer-hosted.
FAQs
Want to see it on your own orgs? Book a personalized demo to see how Flosum can help you track security changes, gate releases, and keep audit-ready evidence across your Salesforce environments.
Thank you for subscribing
