In truth, nobody fully designs a Salesforce org. Orgs happen.
A permission set gets cloned for one project and outlives it by four years. An integration user picks up Modify All Data during a migration weekend and keeps it. A connected app gets authorized by whoever clicked "allow" first.
Ask a mature enterprise three questions: who has access to what, why, and is that still appropriate… and the honest answer is usually a shrug, if not backed by institutional knowledge.
The Security Benchmark for Salesforce (SBS) exists to replace that very shrug.
It's a new, formal, independent compliance standard that defines mandatory, auditable requirements for securing Salesforce environments, the same role CIS Benchmarks play for operating systems and cloud platforms.
Where NIST and ISO define program-level principles, SBS helpfully translates them into Salesforce-specific language: concrete requirements, written against platform behavior, that an org either meets with a yes or doesn't with a no.
As of this writing, the SBS benchmark spans a full 54 controls across 12 domains: access controls, authentication, OAuth security, integrations, deployments, code security, customer portals, data security, file security, event monitoring, security configuration, and a foundations domain that anchors the rest.
It's practitioner-developed and community-maintained on GitHub, with a chief editor overseeing structure and releases.
Two things SBS is not. It's not a cert program, and it doesn't replace regulatory obligations. And it's not a Salesforce product, in their own words: “SBS is not a certification program and does not replace regulatory or compliance obligations. It is an independent initiative, not a Salesforce product, and is not endorsed or supported by Salesforce, Inc.”
How the controls work
Every SBS control follows the same anatomy: a unique ID, a single-sentence requirement, an audit procedure that describes exactly how to check compliance, remediation steps, and usefully Salesforce's default behavior for that setting (which is often the root of the problem).
As stated before, compliance is black-and-white binary.
If a requirement isn't satisfied, the environment is noncompliant. Partial compliance is not recognized. Compensating controls don't count unless your internal security authority formally documents and accepts them. That rigidity is deliberate and important… a standard you can partially meet is a standard nobody meets.
Each control also carries a risk tier, assigned through three questions applied in order:
- Does the control establish a security boundary, meaning its failure alone lets someone gain access or exceed their permissions? Critical.
- Does it provide visibility, meaning its failure lets incidents go undetected or uninvestigated? High.
- Does it add assurance while other controls still provide coverage? Moderate.
SSO enforcement is Critical. Persistent application logging is High. Peer code review is Moderate, as static analysis and testing catch the same issues.
Controls are also tagged against HIPAA, GDPR, NIST, CCPA/CPRA, SOC 2, and ISO 27001… and the tagging philosophy is refreshingly strict. A control gets tagged only when an auditor for that framework would expect to see it as evidence. Most controls map to one to three frameworks, and the maintainers state directly that under-tagging is preferable to over-tagging. In a world of compliance-mapping matrices where every row checks every column, restraint is a credibility signal in our book.
The pattern hiding in the control list
We read all 54 controls in one sitting and a pattern emerged that the domain structure obscures.
Count the recurring phrases: documented justification. Authoritative inventory. System of record. They appear in the access controls domain, the OAuth domain, the integrations domain, the data security domain.
The very first control in the benchmark (SBS-FDNS-001) requires a centralized system of record documenting all security configurations, exceptions, justifications, and required inventories before anything else. SBS is a security benchmark on the front cover and a documentation mandate in Chapter 1.
Comparatively, few controls order you to change a setting.
Most order you to be able to explain your settings (every API-enabled permission, every super-admin-equivalent user, every connected app, every remote site, every SSO bypass) with a written reason, in a maintained record, reviewed on a cadence.
The benchmark's authors say it themselves: SBS doesn't demand perfection. "It requires knowing where you stand."
That framing is helpful because it inverts the usual security posture… The threat model here isn't the usual sophisticated attacker wearing a black hoodie, but rather org-wide amnesia. The org where nobody remembers why the setting is the way it is, so nobody dares touch it, so it stays wrong forever.
Running a gap analysis
A practical sequence, based on how the controls cluster:
Pin your version. Published SBS versions are immutable, but major releases can add, remove, or renumber controls… the benchmark grew from roughly two dozen controls to 54 in its early releases, fairly quickly it seems. Record which version you assessed against, or your audit trail will mean nothing in a year.
Stand up the system of record first. FDNS-001 isn't numbered first by accident. Roughly a third of the remaining controls deposit their evidence ( inventories, justifications, exceptions) into it. Do this without it and you'll end up doing it twice.
Enumerate the cheap domains next. Access controls, OAuth, and integrations are mostly metadata questions: which profiles grant API Enabled, which connected apps were never formally installed, which remote site settings exist and why. This is queryable in hours if you have org visibility, and a quarter-long archaeology project if you don't.
Budget real time for the mechanism controls. Some requirements, like continuous detection of regulated data in long text fields, monitoring for unauthorized metadata changes, demand ongoing capability, not a one-time check. These are where "we'll just do it manually" quietly dies.
Fail honestly. Binary means binary. An inventory that's 90% complete is a noncompliant inventory. Document the exception, assign the remediation, and let the standard do what standards are for.
On tooling: SBS published its full control set as machine-readable XML specifically so vendors can automate assessment, and the maintainers are explicit that the benchmark defines what to check while vendors supply the scanning logic. I think we can expect a gap-analysis tooling ecosystem to form around this quickly.
The chapter that hasn't been written
For all its coverage, the benchmark has a conspicuous blank space: agents. The closest it gets is a strong set of controls on non-human identities… inventory them, restrict their broad privileges, add compensating controls when they're privileged. Necessary, and written for a world of static integration users.
AI agents are non-human identities with another big difference: their action surface changes at runtime. An agent operating inside a Salesforce org authenticates like an integration user but behaves like an employee, one that works at machine speed and never files a ticket. Which permissions it exercises, which records it touches, and which metadata it modifies are questions the current control set doesn't yet ask. It's an open, community-maintained standard, so those controls will get written. The interesting question is by whom.
The deeper idea in SBS holds either way.
The benchmark never asks you to simplify your org. It asks you to make your org legible… every permission explainable, every integration justified, every change attributable.
As we’ve said time and time again here, complexity is never the disqualifying condition. Illegibility is. And an org that can answer the benchmark's questions for an auditor is, not coincidentally, an org that can answer them for anything else you invite inside.
——
For more helpful security in Salesforce news and information, check out our Resources Hub, as well as Security-focused content.
