Here's how the first attempt at this usually goes: A security lead reads about the Security Benchmark for Salesforce, opens the docs, and starts with whatever domain scares them most (usually authentication).
They assess it. They feel good. Then they hit the access controls domain and discover it wants a documented justification for every API-enabled permission, deposited into a system of record.
Then the OAuth domain wants the same for every connected app.
Then integrations, same again.
And there is no system of record, because nobody built one, because that looked like paperwork instead of actual infrastructure.
So they build it mid-assessment. They backfill everything already reviewed, and absorb the fact that they've now done a third of the benchmark twice.
The controls do have an order.
Follow it and the assessment compounds.
Ignore it and the assessment repeats.
This is the sequence to use at your best discretion.
Step 0: Pin your version
Published SBS versions are immutable. Major releases are a different story. They can add, remove, renumber, or recategorize controls, and the benchmark has already grown substantially across its early releases (from 24 a few weeks ago to over 50 as of us writing this).
Before touching a single control, record the version.
Put it at the top of the assessment artifact. Importantly, when the next major release lands, you'll be able to then diff against a fixed point in time, instead of reconstructing what you meant a year ago.
One paragraph of effort. It protects everything else downstream.
Step 1: Stand up the system of record
The foundations domain sits first in the benchmark, and its opening requirement… a centralized system of record for security configurations, exceptions, justifications, and inventories… sits first in that domain.
That placement is structural. A large share of the remaining controls don't just ask you to check something, no rather they ask you to record something: which users hold super-admin-equivalent access and why, which connected apps were formally approved, which SSO exceptions exist and who accepted them. All of that evidence needs a home, and the benchmark expects the home to exist before the evidence arrives.
Be honest about what qualifies.
A spreadsheet owned by someone who left in 2024 is a memorial, and a wiki page nobody has touched since the last audit is basically a fossil of a bygone era. The standard's bar is a maintained record with named ownership and a review cadence. That makes it something a new hire could open and trust.
Teams that skip this step don't skip the work. They defer it, then perform it twice under worse conditions. So it’s vital to build that container first.
Step 2: List the cheap domains
With the system of record standing, go where the answers are cheapest. Access controls, OAuth security, and integrations are mostly metadata questions….
- Which profiles and permission sets grant API Enabled.
- Which connected apps exist that nobody formally installed.
- Which remote site settings are live, and whether anyone can produce a reason for them.
None of this requires new tooling to understand. It requires visibility into configuration your org already contains. With real org visibility, this enumeration is an afternoon. Without it, it's a quarter-long archaeological dig conducted through exported CSVs and the memories of whoever's been around longest.
Either way, the output is the same. Inventories and justifications, deposited into the system of record you built in Step 1. This is where the sequence starts paying compound interest. Every enumerated domain makes the next one faster, because the container and the habit already exist.
Step 3: Budget real time for the mechanism controls
Some controls can indeed be satisfied with a point-in-time check. Others simply can't. Requirements like continuous detection of regulated data in long text fields, or ongoing monitoring for unauthorized metadata changes, describe a capability… something that has to run tomorrow, and next month, and after the admin who set it up changes jobs.
This is the step where "we'll just handle it manually" goes to die a slow painful death. A manual process is just a fancy point-in-time check. It satisfies the control on the day of the assessment and drifts out of compliance the day (maybe an hour) after. Budget for these controls the way you'd budget for standing infrastructure, because that's what they are. If the real answer is that your team can't sustain the mechanism, write that down as a gap (a real one, with an owner and a date) instead of a process that exists only on the org chart.
Step 4: Fail honestly
SBS compliance is binary for a reason. Partial compliance isn't recognized, and compensating controls don't count unless your internal security authority formally documents and accepts them. An inventory that's 90% complete is a noncompliant inventory. There’s no way around it.
This might feel punishing until you appreciate why it's there. Mostly because a standard you can partially meet is a standard nobody meets. Every org becomes "mostly compliant," the term stops carrying information, and the auditor's eyes glaze over. The binary is what makes an SBS assessment worth showing.
So fail where you fail. Document the exception in the system of record, assign the remediation, set the reassessment date, and let the standard do what standards are for. The org that reports twelve honest gaps is in materially better shape than the org that reports zero but can't explain how.
What the sequence actually buys you
Run this once, in order, and you end up with more than a compliance posture. You end up with a legible org. Every permission explainable, every integration justified, every exception owned by a person instead of a shrug. This is really the deeper trade SBS is offering, and we've written before about why it matters beyond audit season: the benchmark never asks you to simplify your org. It asks you to make it answerable.
If you're new to the standard itself (where it came from, how the controls are structured, what it deliberately isn't) start with our full explainer on the Security Benchmark for Salesforce and the official SBS documentation. And if Step 2 read less like an afternoon and more like a quarter, that's the gap worth closing first. (See how Sweep gives you that visibility →)
Note: SBS is an independent, community-maintained initiative. It is not a Salesforce product and is not endorsed by Salesforce, Inc.
