Most Salesforce security conversations start with the question of who has access to your org. But there’s an equally important follow-up: what standard are you securing it against?

For most of Salesforce’s existence, there hasn’t been a good answer. Generic frameworks like NIST SP 800-53 and ISO 27001 provide high-level principles, and Salesforce’s own documentation covers individual features, but nothing has bridged the gap between abstract security controls and Salesforce-specific implementation requirements. The Security Benchmark for Salesforce (SBS) is built to fill that gap.

What SBS Is

SBS is a vendor-neutral, community-driven compliance standard that defines mandatory, auditable requirements for securing Salesforce environments. Think of it as the CIS Benchmarks equivalent for Salesforce: prescriptive controls where each one specifies an explicit requirement, an audit procedure, and a remediation path. Organizations either meet a control or they don’t. There’s no partial credit.

The project is open source, licensed under CC BY-SA 4.0, and published at securitybenchmark.org. Each release includes an XML representation of all controls suitable for automated scanning tools, which means vendors can build SBS compliance checking directly into their products.

What It Covers

SBS organizes controls across eleven domains:

• Foundations
• OAuth Security
• Integrations
• Access Controls
• Authentication
• Code Security
• Customer Portals
• Data Security
• Deployments
• Security Configuration
• File Security
• Event Monitoring

Each domain maps to regulatory requirements from HIPAA, GDPR, NIST, CCPA/CPRA, SOC 2, and ISO 27001. If your organization already aligns to one of those frameworks, SBS gives you the Salesforce-specific implementation detail those frameworks lack.

Why It Matters Now

Salesforce security tooling has matured significantly over the past two years. Shield, Event Monitoring, and the shift to permission sets have given organizations more control over their environments. But tooling without a standard to measure against produces inconsistent outcomes. One team’s “secure” is another team’s audit finding.

SBS provides the common language. Whether you’re an admin hardening your own org, a consultant advising clients, an auditor assessing Salesforce environments, or a vendor building security tooling, the benchmark defines what good looks like in concrete, testable terms.

What to Do With It

• Review the controls at docs.securitybenchmark.org and assess your org against the domains most relevant to your risk profile. Access Controls, Authentication, and Data Security are practical starting points for most organizations.
• If you’re a security vendor or consultancy, look at the machine-readable XML format. Building SBS compliance into your tooling or assessment methodology gives your customers a measurable baseline instead of subjective recommendations.
• If you’re subject to compliance requirements (HIPAA, SOC 2, GDPR), use the regulatory mappings to identify which SBS controls satisfy your existing obligations with Salesforce-specific implementation guidance.
• Contribute. The project is actively maintained on GitHub and welcomes new controls, improvements to existing controls, and documentation enhancements.

Deeper Dive

The Problem SBS Solves

Ask five Salesforce administrators what a “secure org” looks like and you’ll get five different answers. One will focus on MFA enforcement. Another will emphasize field-level security. A third will talk about Shield encryption. All of them are right, and none of them are complete.

This is the core problem: without a comprehensive, prescriptive standard, Salesforce security is defined by whatever the person doing the work happens to know about. An admin who came up through a healthcare organization will prioritize HIPAA-adjacent controls. An admin from financial services will think about SOC 2. Neither will cover the full surface area because neither has a checklist that does.

Generic frameworks don’t solve this. NIST SP 800-53 control AC-6 says “employ the principle of least privilege.” That’s correct and almost useless for a Salesforce admin trying to figure out whether their permission set groups are scoped properly, whether their OAuth connected apps have excessive scopes, or whether their community portal guest user has access to internal objects. SBS translates principles like least privilege into Salesforce-specific controls with testable criteria.

The Eleven Control Domains

Each SBS domain addresses a distinct area of Salesforce security. Here’s what they cover and why each matters.

Foundations

Baseline organizational security settings that affect the entire org. This includes org-wide defaults, company information settings, and foundational configurations that other controls build on. Getting foundations wrong undermines controls in every other domain.

Authentication

How users prove their identity to the org. Controls cover MFA enforcement, session settings, password policies, login IP restrictions, and login hour restrictions. Authentication is the front door, and most orgs have at least one setting that’s weaker than they realize.

Access Controls

What authenticated users can do once they’re in. This domain covers profiles, permission sets, permission set groups, and the principle of least privilege applied to Salesforce’s specific permission model. The shift from profiles to permission sets has made this domain more nuanced–and more important.

OAuth Security

How external applications authenticate to your org and what they can do. Connected apps, OAuth scopes, refresh token policies, and authorization flows. This is the domain that catches most organizations off guard because OAuth access doesn’t show up in the user list and often outlives the engagement that created it.

Integrations

Security controls for system-to-system connections beyond OAuth. Named credentials, external services, integration user configuration, and API access patterns. As orgs become more interconnected, integration security becomes a larger share of the overall attack surface.

Data Security

How data is protected within the org. Field-level security, record-level access (OWDs, sharing rules, manual shares), encryption, and data classification. This domain is where regulatory requirements like GDPR and HIPAA translate most directly into Salesforce-specific controls.

Code Security

Security requirements for custom code: Apex classes, triggers, Visualforce pages, Lightning components, and Flows. Covers CRUD/FLS enforcement in code, SOQL injection prevention, and secure coding patterns specific to the Salesforce platform.

Customer Portals

Security controls for Experience Cloud sites (formerly Communities). Guest user access, portal user permissions, object and field visibility for external users, and authentication settings for self-registration. Customer portals are consistently one of the highest-risk areas in Salesforce security because they expose org data to unauthenticated or low-trust users.

Deployments

Security controls around how changes move into the org. Change sets, metadata API deployments, DevOps processes, and sandbox management. Insecure deployment pipelines can bypass security controls that are enforced in production.

Security Configuration

Org-level security settings that don’t fit neatly into other domains. Certificate management, CORS settings, CSP directives, trusted IP ranges, and platform security features like Clickjack protection. These are the settings that often get configured once during implementation and never reviewed again.

File Security

Controls for how files and attachments are handled in the org. Upload restrictions, file type filtering, content delivery settings, and attachment security. File-based attacks are an underappreciated vector in Salesforce environments.

Event Monitoring

Requirements for logging, monitoring, and alerting on security-relevant events. Transaction Security policies, Event Monitoring analytics, login forensics, and audit trail configuration. You can’t detect what you don’t monitor, and most orgs monitor far less than they should.

Running a Self-Assessment

SBS controls are designed to be testable. Here’s a practical approach to assessing your org.

Start with the Highest-Risk Domains

Not every domain carries equal weight for every organization. Prioritize based on your org’s profile:

• If you have Experience Cloud sites: start with Customer Portals. Guest user misconfigurations have been the source of the most publicized Salesforce data exposures.
• If you have significant custom development: start with Code Security. CRUD/FLS enforcement gaps in Apex are common and difficult to detect without deliberate review.
• If you rely on third-party integrations: start with OAuth Security and Integrations. Third-party access is one of the largest and least-monitored attack surfaces.
• If you’re preparing for a compliance audit: start with the domain that maps to your regulatory framework and work outward.

Use the Machine-Readable Format

Each SBS release includes an XML representation of all controls. If you have internal tooling, a Salesforce DevOps pipeline, or a security scanning platform, the XML format allows you to automate compliance checking rather than relying on manual review. Vendors building Salesforce security products can integrate SBS controls directly into their scanning logic.

Document Exceptions

Not every control will apply to every org, and that’s expected. What matters is that deviations are deliberate and documented. An org that consciously accepts a risk and documents the rationale is in a fundamentally different position from an org that never evaluated the control at all.

Reassess on a Cadence

SBS is versioned (the latest release is v0.4.1). As the benchmark evolves and your org changes, periodic reassessment ensures that controls that were passing six months ago haven’t drifted. Major org changes–new integrations, new Experience Cloud sites, new custom development–should trigger a targeted reassessment of the relevant domains.

How SBS Compares to Existing Frameworks

CIS Benchmarks

The Center for Internet Security publishes benchmarks for operating systems, cloud platforms (AWS, Azure, GCP), databases, and applications. There is no CIS Benchmark for Salesforce. SBS fills that gap using the same philosophy: prescriptive, binary, auditable controls organized by domain.

CSA Critical Controls for Salesforce

The Cloud Security Alliance published 20 critical controls for Salesforce. These provide useful guidance but are higher-level than SBS. The CSA controls describe categories of things to secure (authentication, data protection, monitoring). SBS specifies exactly how to secure them in Salesforce, with testable criteria for each control.

NIST SP 800-53 and ISO 27001

Both frameworks provide comprehensive security control catalogs, but neither addresses Salesforce-specific implementation. SBS maps its controls to both frameworks, so organizations that are already aligned to NIST or ISO can use SBS as the translation layer between their existing compliance posture and their Salesforce environment.

For Vendors and Consultancies

SBS is designed to be adopted by the ecosystem, not just individual organizations.

If you build Salesforce security tooling, integrating SBS controls into your product gives customers an objective way to measure what your tool catches and what it doesn’t. The machine-readable XML format is built for this use case.

If you run Salesforce security assessments or health checks, SBS provides a standardized methodology that’s more defensible than a custom checklist. Clients can compare assessments across vendors when everyone is measuring against the same standard.

If you’re an SI or managed service provider, demonstrating SBS alignment in the orgs you manage is a differentiator. It shows clients that your security posture isn’t ad hoc.

The Bottom Line

The Salesforce ecosystem has operated without a dedicated security benchmark for over two decades. During that time, organizations have relied on a patchwork of generic frameworks, Salesforce documentation, tribal knowledge, and whatever their most security-aware admin happened to know. The result is inconsistency: two orgs in the same industry, subject to the same regulations, with the same Salesforce products, can have wildly different security postures simply because different people made different assumptions about what “secure” means.

SBS eliminates the ambiguity. It defines what secure means for Salesforce in concrete, testable terms. Whether you use it as a self-assessment tool, a compliance framework, or a foundation for your security practice, the benchmark exists now and it’s open to everyone.

The question from earlier applies here too: what standard are you securing your org against? If the answer is “we don’t have one,” now you do.

Book a 15-Minute Security Strategy Call

Reference(s):

https://www.securitybenchmark.org/

https://docs.securitybenchmark.org/

https://github.com/Salesforce-Security-Benchmark/docs-site

https://cloudsecurityalliance.org/artifacts/critical-controls-implementation-for-salesforce

‍