Misconfigured CRM settings remain one of the fastest paths to a data breach. Weak password policies expose regulated data and trigger compliance violations that cost enterprises millions in fines.

Salesforce bundles a powerful response inside Setup: Health Check. The dashboard analyzes security settings, ranks each one by risk level, and creates a 0-to-100 score that tracks improvement over time. Health Check surfaces misconfigurations before attackers spot them, supporting SOX §404 "adequate internal controls" requirements and GDPR Art 32 "appropriate technical measures" standards.

Configuration drift erodes security posture with every new user and integration. Health Check provides a repeatable way to catch drift early and prove continuous compliance.

This approach transforms periodic security reviews into continuous compliance. The framework covers baseline security scoring, high-risk finding triage, custom baseline uploads, profile auditing, automated CI/CD gates, audit documentation, and multi-org scaling.

Here are the steps you should take to reduce risk, satisfy auditors, and keep Salesforce environments defensible over time using Salesforce Health Check.

1. Capture the Baseline Security Score and Prioritize High-Risk Findings

Establish a defensible baseline before changing any security settings. This becomes the foundation for every fix, audit conversation, and regression test. Without that snapshot, teams cannot prove improvement or trace regressions during future assessments.

Navigate to Setup ➜ Security ➜ Health Check and run the scan. Salesforce assigns a 0-100% score and groups settings into four risk categories: High-Risk, Medium-Risk, Low-Risk, and Informational. Understanding these categories helps prioritize remediation efforts based on actual security impact rather than arbitrary preferences.

Scores in the 90-100% range indicate strong alignment with Salesforce standards. 80-89% signals emerging gaps requiring attention. Below 80% typically reflects multiple high-risk findings that could violate SOX §404 or GDPR Art 32 controls and create direct pathways for privilege escalation and data exfiltration.

After the scan completes, preserve the baseline and identify priority areas for immediate action:

• Export the CSV of findings and store in version control
• Screenshot the dashboard to capture the exact gauge and timestamp
• Archive both files in a read-only location tied to the current release
• Review high-risk findings first as these represent immediate security threats and raise scores most quickly

Focus initial remediation efforts on high-risk settings that create the largest compliance gaps. Password policies establish the first defense line against brute-force attacks and should require a minimum length of 12 characters, mixed case with numbers and symbols, and 90-day expiration. Session security settings prevent unauthorized access to abandoned sessions by reducing timeouts to 15-30 minutes, enabling forced logout on session lock, and restricting login IPs to trusted ranges.

Additional high-priority fixes include enabling clickjack protection to stop UI redress attacks and implementing multi-factor authentication to close credential-based attack vectors. Each remediation supports SOX §404 internal control requirements and GDPR Art 32 "appropriate technical measures," providing defensible proof of access protection.

For recurring releases, automate security health score captures through Salesforce's Tooling API rather than relying on manual dashboard checks. The SecurityHealthCheck object provides programmatic access to your organization's security health score, which reflects adherence to Salesforce security best practices, including password policies, session settings, and network access controls. Teams can integrate this data capture into CI/CD pipelines or automated scripts by executing a simple SOQL query:

SELECT Score FROM SecurityHealthCheck

This query retrieves the current numerical security score, which can then be stored in build artifacts, compared against previous baselines, or used to trigger alerts when scores drop below acceptable thresholds. The data flows directly into build artifacts, eliminating manual errors and creating an audit trail. This baseline enables teams to measure security improvements with concrete numbers rather than subjective assessments.

Legacy integrations often break when hardening controls, so test changes in full sandboxes that mirror production integrations. Issue Connected App OAuth tokens with IP relaxations only when necessary and schedule cutovers during low-traffic windows. For complex environments, roll out fixes in phases: internal users first, then external partners, finally system integrations while tracking incremental score improvements after each wave to prove progress and maintain stakeholder engagement.

2. Audit Profiles and Permission Sets for Least-Privilege Access

A perfect Health Check score doesn't protect your data if users can access information they don't need for their jobs. The safest approach gives each person only the minimum permissions required to do their work—nothing more. This is commonly referred to as “least privilege access.”

When users have too much access, it creates security risks. Over time, permissions pile up as people change roles or take on temporary projects. These leftover permissions become security gaps that can lead to data breaches and compliance problems.

Start by looking at what the Health Check found and compare it to your current user roles. Many security issues come from old user profiles that were never cleaned up or permission sets that nobody remembers creating.

Follow this systematic approach to identify over-privileged access:

• Export results and filter for access control settings
• Map each finding to profiles or permission sets that grant it
• Open the Profiles view and search for "View All" or "Modify All" object rights
• Flag profiles where rights exceed documented responsibilities

Permission sets often accumulate over time as temporary solutions become permanent fixtures. Clean up these legacy assignments by focusing on critical roles first:

• Remove sets that duplicate profile access or represent abandoned experiments
• 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 complete, establish sustainable access patterns that prevent future privilege creep. This foundation supports long-term security without hampering productivity:

• Build lean, department-level profiles as the foundation
• Grant exceptions through additive permission sets that expire when projects end
• Require approval workflows for new privilege sets, embedding separation of duties into requests

Document each Role-Based Access Control (RBAC) decision to satisfy auditors and support a comprehensive security posture. The trail links every permission change to a user and timestamp, eliminating spreadsheet sprawl and shortening evidence collection during SOX or GDPR reviews.

Schedule quarterly permission reviews to catch configuration drift. The dashboard surfaces misconfigurations, but only reviews can validate that real-world access matches policy. When reviews find drift, remediate in a sandbox, run another scan to confirm fixes, and promote with proper change controls. A regular review cadence turns least-privilege from one-time cleanup into sustained control that protects sensitive data without slowing business operations.

3. Embed Health Check Gates in the CI/CD Pipeline

If you only run security scans after deploying changes to production, you're merely documenting problems that have already occurred. Embedding them in pipelines turns every commit into a real-time security review. Automated scans catch security problems before they reach your live system and create a permanent record that auditors can review

Connect Health Check to Your Deployment Pipeline

The SecurityHealthCheck and SecurityHealthCheckRisks objects are queryable. To automatically check security during deployments, you need to connect your build system to Salesforce's Health Check data. This means writing a script that can log into Salesforce, pull the current security score, and stop deployments if the score is too low.

Salesforce stores Health Check results in database objects called SecurityHealthCheck and SecurityHealthCheckRisks. Your deployment pipeline can query these objects just like any other Salesforce data. Here's how a typical security gate works:

1. Authenticate - Log into Salesforce using API credentials
2. Check score - Query the current Health Check percentage
3. Make decision - Compare the score against your minimum threshold
4. Block or allow - Stop the deployment if security standards aren't met

The script below shows this process in action. It connects to Salesforce, pulls the latest security score, and blocks deployment if the score drops below 90%:

# --- ci/jobs/healthcheck.sh ---

# 1) Authenticate with JWT flow

sfdx force:auth:jwt:grant \

  --clientid $SF_CLIENT_ID \

  --jwtkeyfile ./server.key \

  --username ci-bot@company.com \

  --instanceurl https://login.salesforce.com

# 2) Pull the latest Health Check score

SCORE=$(sfdx force:data:soql:query \

  -q "SELECT Score FROM SecurityHealthCheck" -u ci-bot@company.com \

  --json | jq -r '.result.records[0].Score')

# 3) Enforce the gate

THRESHOLD=90

if [ "$SCORE" -lt "$THRESHOLD" ]; then

  echo "Health Check score $SCORE is below $THRESHOLD — blocking deployment."

  exit 1

fi

echo "Health Check score $SCORE meets threshold."

Configure Threshold Strategy by Environment

Not every environment needs the same security threshold. Your development sandbox can be more relaxed than production, but you still want to catch problems before they become serious.

Think about what makes sense for each environment:

• Development and testing environments: Set warnings when scores drop below your target. This gives developers a heads-up about security issues without stopping their work. If someone is experimenting with new features, a temporary dip in security score shouldn't halt progress.
• Production environment: Use a hard stop at 90% or higher. Production affects real users and contains live data, so security problems here have real consequences. Don't let anything deploy if it weakens your security posture.
• Organizations with custom security policies: Match your pipeline thresholds to the custom baselines you uploaded. If your company requires stricter password policies than Salesforce's defaults, your deployment gates should enforce those same standards.
• Special cases: Keep a list of intentional exceptions. Sometimes you need to deploy something that temporarily lowers your score for legitimate business reasons. Document these cases so your pipeline knows when to allow them through.

You can also focus on the most critical issues by checking for high-risk problems specifically, even when your overall score looks okay. Add this query to your pipeline to catch serious vulnerabilities that might not show up in the overall percentage:

# Check for any high-risk findings

HIGH_RISK_COUNT=$(sfdx force:data:soql:query \

  -q "SELECT COUNT() FROM SecurityHealthCheckRisks WHERE RiskType='HIGH_RISK'" \

  -u ci-bot@company.com --json | jq -r '.result.totalSize')

if [ "$HIGH_RISK_COUNT" -gt "0" ]; then

  echo "Found $HIGH_RISK_COUNT high-risk security issues — blocking deployment."

  exit 1

fi

A single serious vulnerability might not tank your percentage, but it could still pose a real threat.

Benefits of Automated Security Gates

Setting up automated security checks in your deployment pipeline does more than just catch problems - it fundamentally changes how your team works with security. Instead of security being something you think about after deployments go wrong, it becomes part of your normal development process.

Here's what happens when you automate these checks:

• Catch problems when they're easy to fix: When a developer makes a change that weakens security, they find out immediately - not weeks later when someone runs a manual audit. At that point, the fix might be changing a single line of code instead of unraveling a complex deployment.
• Build compliance evidence automatically: Every time your pipeline runs, it creates a timestamped record of your security score. When auditors show up asking for proof that you're following security protocols, you have months of data ready to go instead of scrambling to recreate what happened.
• Prevent environment surprises: Nothing is worse than having something work perfectly in your development environment, then fail in production because of different security settings. Automated gates ensure your security standards are the same everywhere, so you avoid those "it worked in my sandbox" moments.

The technical implementation is straightforward — if you're already using Salesforce CLI in your deployment pipeline, adding a security check usually means adding one more step to your existing process. You can combine this with code quality tools to create a comprehensive quality gate that checks both functionality and security before anything reaches production.

4. Document Every Fix for Audit-Ready Evidence

When auditors arrive, they want to see proof that you actually fixed the security problems you found. "We think we fixed that" isn't good enough — you need documentation showing exactly what was broken, who fixed it, how they fixed it, when they fixed it, and how you know it worked. Complete documentation transforms security tweaks into verifiable controls that satisfy SOX and GDPR requirements.

Standardize Remediation Logging

Documentation requires a consistent structure to remain searchable and useful across multiple audit cycles. When you're rushing to close security gaps, it's tempting to fix first and document later — but that's when important details get forgotten.

For each security issue you address, record:

• What you found: The specific Health Check finding (like "Password policy too weak")
• Risk level: How serious the problem was (High, Medium, Low)
• What you did: The actual changes you made ("Changed minimum password length from 8 to 12 characters")
• Who approved it: The person who signed off on the change
• When it happened: Date and time of the fix
• Proof it worked: Screenshots, before/after scores, or test results

Don't rely on your memory or informal notes. Use the documentation that your tools create automatically whenever possible. Version control systems track code changes, Salesforce keeps logs of configuration changes, and your deployment tools record what happened when. These automatic records are much more credible to auditors than manual spreadsheets.

However, be aware that Salesforce Change Sets don't automatically track detailed deployment history, so if that's your deployment method, you'll need additional documentation or consider using version control tools.

Set Up Approval Processes That Auditors Trust

Auditors are skeptical of informal approval processes. Email chains where someone says "looks good to me" don't carry much weight. Instead, use systems that create clear, tamper-proof records of who approved what and when.

When someone needs to fix a high-risk security issue, route the change through your official approval process, whether that's a compliance officer, security team, or change control board. Make sure the approval system timestamps everything and identifies who made each decision.

Store all this documentation somewhere secure and permanent. Daily exports to encrypted storage or your governance system ensure you can't accidentally delete audit evidence. Spreadsheets stored on someone's laptop are not audit-ready documentation.

Complete, automated documentation gives security and DevOps teams the feedback loop needed to refine processes and prove continuous improvement. Making every fix traceable from initial finding to production deployment solidifies both internal governance and external compliance posture.

5. Re-Run, Trend, and Scale Across Salesforce Environments

Security issues don't announce themselves — they creep in gradually as people make changes, add new users, or update integrations. Running Health Check scans regularly helps you spot problems before they become serious vulnerabilities.

When to Run Security Scans

Don't just scan randomly. Set up a schedule based on when problems are most likely to appear:

• Right after you fix something: Always run a new scan immediately after making security changes to confirm your fixes actually worked. It's frustrating to think you've solved a problem only to discover it's still there weeks later.
• After major releases: New features, integrations, or significant changes often introduce security gaps. Scan after each major deployment to catch issues while the changes are fresh in everyone's mind.
• Quarterly maintenance scans: Even when nothing major is happening, run scans every three months. This catches gradual drift — like expired certificates, abandoned user accounts, or slowly weakening passwords.
• When policies change: If your company updates security requirements (like requiring longer passwords or mandatory MFA for new departments), scan all your environments to see which ones need updates.

Keep Track of Your Security History

One scan tells you how you're doing today. Multiple scans over time show you patterns and help you predict where problems might develop.

Set up a simple script to automatically save your Health Check scores and findings. Here's an example that pulls today's score and saves it to a file:

# Get today's security score and save it

sfdx force:org:display --json | jq '.result.instanceUrl' > url.txt

curl -H "Authorization: Bearer $ACCESS_TOKEN" \

  "$(cat url.txt)/services/data/v59.0/tooling/query/?q=SELECT+Score,CreatedDate+FROM+SecurityHealthCheck" \

  >> healthcheck-history.json

After a few months, you'll start seeing useful patterns. Maybe your security scores always dip right after release cycles. Maybe you have persistent problems with session timeout settings. Or maybe your monitoring stopped working and nobody noticed because the scores flatlined.

Scale Across Multiple Salesforce Environments

If you're managing production, development, and testing environments — plus maybe regional offices or subsidiaries — you need a way to see the big picture without logging into each environment individually.

Feed all your Health Check data into one central location so you can rank environments by risk level and focus your attention where it's needed most. Salesforce Security Center can help with cross-environment visibility, and Salesforce Optimizer points out feature-specific gaps.

Remember to keep your security standards consistent across environments. When you update password requirements or roll out MFA to new teams, update your custom baselines in all environments so your trending data stays meaningful.

As you manage more environments, automate as much as possible. Set up alerts when scores drop below your thresholds, automate daily scans, and create dashboards that refresh automatically. This scales much better than trying to remember to check everything manually.

6. Create and Upload a Custom Baseline That Reflects Your Security Standards

After completing the foundational security improvements, Salesforce's standard baseline may still fall short of your organization's specific compliance requirements. A custom baseline defines what "secure" means for your environment, measuring against internal policies rather than generic thresholds.

Building Your Custom Baseline Strategy

Creating an effective custom baseline requires understanding which controls matter most for your industry and risk profile. Financial services organizations typically need stricter password policies, mandatory MFA for all users, and session timeouts under 2 hours. Healthcare environments require enhanced audit logging and restricted data export capabilities.

Start by exporting your current baseline to understand existing gaps. Navigate to the dashboard and click Download Baseline, and Salesforce delivers a JSON file listing each security setting, its risk category, and the default standardValue. This file becomes your starting template for customization.

Focus your customization efforts on settings that address your biggest vulnerabilities and compliance requirements:

• Password policies: Increase minimum length, complexity requirements, and expiration frequency
• Session management: Reduce timeout windows and restrict concurrent sessions
• API security: Lower allowed login failures and mandate IP restrictions
• Data protection: Enable field-level encryption and restrict export permissions

Customizing Baseline Thresholds

Open the exported JSON file and modify the standardValue fields based on your security requirements. Each setting includes a risk category and current threshold that you can adjust to match your organization's policies. The modification process involves changing numerical values or Boolean settings to create stricter controls than the Salesforce defaults.

{

  "setting": "MinimumPasswordLength",

  "group": "Password Policies", 

  "riskType": "HIGH_RISK",

  "standardValue": "12"

},

{

  "setting": "SessionTimeout",

  "group": "Session Settings",

  "riskType": "MEDIUM_RISK", 

  "standardValue": "120"

},

{

  "setting": "LoginAttemptsBeforeLockout",

  "group": "Login Policies",

  "riskType": "HIGH_RISK",

  "standardValue": "3"

}

Avoid over-tightening controls that can break legitimate workflows and create user friction. Unrealistic thresholds may lock out legacy integrations or prevent mobile users from accessing the system effectively. If your sales team uses mobile devices extensively, overly restrictive session timeouts will disrupt their daily operations.

Document your rationale for each change with business justifications or compliance requirements. This creates an audit trail and helps future administrators understand the security decisions. Comment each modification to preserve institutional knowledge about why specific thresholds were chosen.

Testing and Implementation

Before deploying to production, validate your custom baseline in a sandbox environment to prevent operational disruptions. Testing ensures that tightened security controls do not interfere with existing business processes or user workflows. Proper validation prevents the need to roll back changes after discovering compatibility issues in production.

Run comprehensive tests to verify system functionality under the new security constraints:

• Run regression tests to confirm existing integrations continue functioning with tightened security controls
• Test user workflows to verify SSO logins succeed, mobile access works as expected, and automated jobs aren't blocked by new restrictions
• Measure the impact by checking how dramatically your score changes — a 20-30 point improvement suggests realistic thresholds while a 50+ point jump may indicate over-tightening

Uploading and Monitoring

Once validated, implement your custom baseline through the Health Check interface. The upload process immediately recalculates your security score based on the new thresholds you have defined. Salesforce will display a Custom Baseline banner to indicate that non-standard criteria are being used for evaluation.

Follow these steps to deploy and monitor your custom baseline:

1. Return to the Health Check dashboard
2. Select Upload Custom Baseline and choose your modified JSON file
3. Salesforce immediately recalculates your score and displays a Custom Baseline banner
4. Capture the new score via the Tooling API's SecurityHealthCheck object for ongoing monitoring

Schedule quarterly reviews to keep your baseline aligned with evolving requirements. Regulatory requirements change over time, and your baseline should adapt accordingly to maintain compliance effectiveness. Version-control your JSON file, document changes with commit messages linking to compliance tickets, and periodically reconcile thresholds with current policy.

A well-designed custom baseline transforms Health Check from a generic assessment into a precise measurement of your security posture against the standards that actually matter for your organization.

Turn Health Check Into a Continuous Compliance Framework

Salesforce Health Check transforms one-time security scans into continuous compliance monitoring. When embedded into daily operations, it creates a defensive framework that satisfies regulatory requirements without slowing development cycles.

However, implementing this framework successfully requires reliable backup and recovery capabilities, deployment tools that automatically enforce security gates, and audit trails that connect every security change to your broader DevOps processes. Manual processes break down when managing multiple environments, complex deployment pipelines, and strict compliance requirements.

Flosum's DevOps and Backup & Archive solutions provide the foundation that makes continuous security monitoring practical for enterprise teams. From automated Health Check integration to granular rollback capabilities, the platform handles the technical complexity so you can focus on maintaining security without sacrificing development velocity. Request a demo to see how Flosum supports enterprise security frameworks and regulatory requirements.