Appearance
ISO 27001 Controls
This page lists SBS controls tagged for this regulation or framework. The mappings are indicative only and help readers identify controls that directly support demonstrating compliance.
These entries are an index into the benchmark. The canonical control content remains on the benchmark pages.
- Total tagged controls: 50
- Benchmark sections represented: 11
Controls By Benchmark Section
Access Controls
12 control(s) in this benchmark section.
SBS-ACS-001: Enforce a Documented Permission Set Model
High Source pageControl Statement: All permission sets, permission set groups, and profiles must conform to a documented model maintained in a system of record and enforced continuously.
Why tagged: Access control and information access restriction (A.5.15–A.5.18, A.8.3); documented model supports Annex A.
SBS-ACS-002: Documented Justification for All API-Enabled Authorizations
High Source pageControl Statement: Every authorization granting the API Enabled permission must have documented business or technical justification recorded in a system of record.
Why tagged: Access control and privilege management (A.5.15–A.5.18); documented justification for elevated access.
SBS-ACS-003: Documented Justification for Approve Uninstalled Connected Apps Permission
Critical Source pageControl Statement: The Approve Uninstalled Connected Apps permission must only be assigned to highly trusted users with documented justification and must not be granted to end-users.
Why tagged: Access control (A.5.15–A.5.18); restricting which applications can be authorized is an expected control.
SBS-ACS-004: Documented Justification for All Super Admin–Equivalent Users
High Source pageControl Statement: All users with simultaneous View All Data, Modify All Data, and Manage Users permissions must be documented in a system of record with clear business or technical justification.
Why tagged: Privileged access rights (A.5.18); justification and documentation for administrative access are required.
SBS-ACS-005: Only Use Custom Profiles for Active Users
High Source pageControl Statement: All active users must be assigned custom profiles. The out-of-the-box standard profiles must not be used.
Why tagged: Access control and secure configuration (A.5.15–A.5.18, A.8.3); organization-defined access boundaries.
SBS-ACS-006: Documented Justification for Use Any API Client Permission
Critical Source pageControl Statement: The Use Any API Client permission, which bypasses default behavior in orgs with "API Access Control" enabled, must only be assigned to highly trusted users with documented justification and must not be granted to end-users.
Why tagged: Access control (A.5.15–A.5.18); controlling and justifying API client access is an expected control.
SBS-ACS-007: Maintain Inventory of Non-Human Identities
High Source pageControl Statement: Organizations must maintain an authoritative inventory of all non-human identities, including integration users, automation users, bot users, and API-only accounts.
Why tagged: Account management and asset management (A.5.15, A.8.1); inventory of identities is required.
SBS-ACS-008: Restrict Broad Privileges for Non-Human Identities
High Source pageControl Statement: Non-human identities must not be assigned permissions that bypass sharing rules or grant administrative capabilities unless documented business justification exists.
Why tagged: Access control and least privilege (A.5.15–A.5.18); privileged access for system accounts must be justified.
SBS-ACS-009: Implement Compensating Controls for Privileged Non-Human Identities
Moderate Source pageControl Statement: Non-human identities with permissions that bypass sharing rules or grant administrative capabilities must have compensating controls implemented to mitigate risk.
Why tagged: Defense-in-depth and secure system engineering (A.8.2); compensating controls for privileged access.
SBS-ACS-010: Enforce Periodic Access Review and Recertification
Moderate Source pageControl Statement: All user access and configuration influencing permissions and sharing must be formally reviewed and recertified at least annually by designated busines stakeholders, with documented approval and remediation of unauthorized or excessive access.
Why tagged: Access control and removal of access rights (A.5.18); periodic access review is an Annex A expectation.
SBS-ACS-011: Enforce Governance of Access and Authorization Changes
High Source pageControl Statement: All changes to Salesforce user access and authorization must be governed through a documented process that requires approval, records business justification, and produces an auditable record of the change.
Why tagged: Change management and access control (A.8.3.2, A.5.18); governed access changes with audit trail.
SBS-ACS-012: Classify Users for Login Hours Restrictions
Moderate Source pageControl Statement: Organizations must maintain a documented classification of users requiring login hours restrictions or equivalent off-hours authentication monitoring.
Why tagged: Access control (A.5.15–A.5.18); time-based or monitored access for sensitive roles where appropriate.
Authentication
4 control(s) in this benchmark section.
SBS-AUTH-001: Enable Organization-Wide SSO Enforcement Setting
Critical Source pageControl Statement: Salesforce production orgs must enable the org-level setting that disables Salesforce credential logins for all users.
Why tagged: Access control (A.5.15–A.5.18); authentication and identity management are Annex A requirements.
SBS-AUTH-002: Govern and Document All Users Permitted to Bypass Single Sign-On
Moderate Source pageControl Statement: All users who do not have the "Is Single Sign-On Enabled" permission must be explicitly authorized, documented in a system of record, and limited to approved administrative or break-glass use cases.
Why tagged: Access control and privilege management (A.5.15–A.5.18); documented exceptions are expected.
SBS-AUTH-003: Prohibit Broad or Unrestricted Profile Login IP Ranges
Moderate Source pageControl Statement: Profiles in Salesforce production orgs must not contain login IP ranges that effectively permit access from the full public internet or other overly broad ranges that bypass network-based access controls.
Why tagged: Access control (A.5.15–A.5.18); network and connection restrictions support secure access.
SBS-AUTH-004: Enforce Strong Multi-Factor Authentication for External Users with Substantial Access to Sensitive Data
Critical Source pageControl Statement: All Salesforce interactive authentication flows for external human users with substantial access to sensitive data must enforce multi-factor authentication that includes at least one strong authentication factor.
Why tagged: Access control and authentication (A.5.15–A.5.18); strong authentication for sensitive access.
Code Security
4 control(s) in this benchmark section.
SBS-CODE-001: Mandatory Peer Review for Salesforce Code Changes
Moderate Source pageControl Statement: All Salesforce code changes must undergo peer review and receive approval before merging into any production-bound branch.
Why tagged: Secure system engineering (A.8.2.4) and change management (A.8.3.2); peer review is a named requirement.
SBS-CODE-002: Pre-Merge Static Code Analysis for Apex and LWC
Moderate Source pageControl Statement: Static code analysis with security checks for Apex and Lightning Web Components must execute successfully before any code change is merged into a production-bound branch.
Why tagged: Secure system engineering (A.8.2.4); managing technical vulnerabilities and secure development are required.
SBS-CODE-003: Implement Persistent Apex Application Logging
High Source pageControl Statement: Organizations must implement an Apex-based logging framework that writes application log events to durable Salesforce storage and must not rely on transient Salesforce debug logs for operational or security investigations.
Why tagged: Logging (A.8.15); events must be recorded and retained for incident investigation and evidence.
SBS-CODE-004: Prevent Sensitive Data in Application Logs
Critical Source pageControl Statement: Custom application logging frameworks and Salesforce system logging mechanisms must not capture, store, or transmit credentials, authentication tokens, personally identifiable information (PII), regulated data, or other sensitive values in log messages or structured log fields.
Why tagged: Logging (A.8.15) and information security in development; logs must not expose sensitive information.
Customer Portals
5 control(s) in this benchmark section.
SBS-CPORTAL-001: Prevent Insecure Direct Object Reference (IDOR) in Portal Apex
Critical Source pageControl Statement: All Apex methods exposed to Experience Cloud or customer portal users must enforce server-side authorization for every record accessed or modified. User-supplied parameters (including record IDs, filters, field names, or relationship references) must not be trusted as the basis for access control and must be validated against the running user's sharing, CRUD, and FLS permissions before use.
Why tagged: Access control and information access restriction (A.5.15–A.5.18, A.8.3); authorization boundary.
SBS-CPORTAL-002: Restrict Guest User Record Access
Critical Source pageControl Statement: Unauthenticated guest users in customer portals must be restricted to authentication and registration flows only, with no direct access to business objects or custom Apex methods that query organizational data.
Why tagged: Access control (A.5.15–A.5.18); unauthenticated access to information assets must be restricted.
SBS-CPORTAL-003: Inventory Portal-Exposed Apex Classes and Flows
High Source pageControl Statement: Organizations must maintain an authoritative inventory of all Apex classes and Autolaunched Flows exposed to Experience Cloud sites, documenting which components are accessible to external and guest users.
Why tagged: Asset management and access governance require an inventory of externally exposed components and who can access them.
SBS-CPORTAL-004: Prevent Parameter-Based Record Access in Portal-Exposed Flows
Critical Source pageControl Statement: Autolaunched Flows exposed to customer portal users must not accept user-supplied input variables that directly determine which records are accessed.
Why tagged: Access control (A.5.15–A.5.18, A.8.3); flows must not create unauthorized data access paths.
SBS-CPORTAL-005: Conduct Penetration Testing for Portal Security
High Source pageControl Statement: Organizations with Experience Cloud sites must conduct penetration testing of portal security controls before initial go-live and subsequently after major releases or on a defined cadence.
Why tagged: Managing technical vulnerabilities and secure system engineering (A.8.8, A.8.2.4) directly support security testing.
Data Security
2 control(s) in this benchmark section.
SBS-DATA-003: Maintain Tested Backup and Recovery for Salesforce Data and Metadata
High Source pageControl Statement: Salesforce production orgs must maintain a documented backup and recovery capability for Salesforce data and metadata, and must test restoration on a defined schedule.
Why tagged: Backup and restoration are direct ISO 27001 controls for resilience and recovery capability.
SBS-DATA-004: Require Field History Tracking for Sensitive Fields
High Source pageControl Statement: The organization must maintain a documented list of sensitive fields and ensure Field History Tracking is enabled for each listed field on all in-scope objects.
Why tagged: Audit logging and change traceability for sensitive data are directly supported by ISO 27001 logging and monitoring objectives.
Deployments
5 control(s) in this benchmark section.
SBS-DEP-001: Require a Designated Deployment Identity for Metadata Changes
High Source pageControl Statement: Salesforce production orgs must designate a single deployment identity that is exclusively used for all metadata deployments and high-risk configuration changes performed through automated or scripted release processes.
Why tagged: Privileged access control, identification, and change management require attributable deployment accounts.
SBS-DEP-002: Establish and Maintain a List of High-Risk Metadata Types Prohibited from Direct Production Editing
High Source pageControl Statement: Salesforce production orgs must maintain an explicit list of high-risk metadata types that must never be edited directly in production by human users, defaulting at minimum to the SBS baseline list while allowing organizations to extend or refine it as needed.
Why tagged: Access restriction and change management require formally defined limits on direct production modification of high-risk metadata.
SBS-DEP-003: Monitor and Alert on Unauthorized Modifications to High-Risk Metadata
High Source pageControl Statement: Salesforce production orgs must implement a monitoring capability that detects and reports any modification to high-risk metadata performed by a user other than the designated deployment identity.
Why tagged: Logging and monitoring controls require detection and review of unauthorized changes to high-risk configuration.
SBS-DEP-005: Implement Secret Scanning for Salesforce Source Repositories
Critical Source pageControl Statement: Organizations using source-driven development for Salesforce must implement automated secret scanning on all repositories containing Salesforce metadata, configuration, or deployment scripts to detect and prevent the exposure of credentials, access tokens, and other sensitive authentication material.
Why tagged: Secure development and protection of authentication secrets are direct ISO 27001 expectations for preventing credential exposure in source control.
SBS-DEP-006: Configure Salesforce CLI Connected App with Token Expiration Policies
High Source pageControl Statement: Organizations must configure the Connected App used for Salesforce CLI authentication with refresh token expiration of 90 days or less and access token timeout of 15 minutes or less.
Why tagged: Access control and secure authentication require restrictions on token lifetime and session timeout.
Event Monitoring
5 control(s) in this benchmark section.
SBS-MON-001: Enable Event Monitoring Log Storage
High Source pageControl Statement: Organizations using Salesforce Event Monitoring must ensure that storage of required Event Monitoring logs is enabled for all event types necessary to support the organization's security monitoring and compliance policies.
Why tagged: Logging controls require required security events to be generated and retained for investigation and evidence.
SBS-MON-002: Retaining Event Logs
High Source pageControl Statement: Organizations must retain security event logs for the defined retention period and implement measures to protect the logs from tampering and unauthorized deletion to ensure forensic availability.
Why tagged: Logging and evidence-retention controls require security logs to remain available and protected from tampering.
SBS-MON-003: Monitor for Suspicious Logins
High Source pageControl Statement: Organizations must continuously monitor and alert on anomalous login patterns to promptly detect and mitigate compromised accounts and application credentials.
Why tagged: Logging and monitoring controls require detection and investigation of anomalous authentication events.
SBS-MON-004: Monitor for Suspicious API Activity
High Source pageControl Statement: Organizations must continuously monitor and alert on all API activity to establish a baseline, detect anomalous and malicious activity, and identify potential application and integration abuse in a timely manner.
Why tagged: Logging and monitoring controls require organizations to analyze detailed activity logs for suspicious API behavior.
SBS-MON-005: Monitor API Usage Against Limits
Moderate Source pageControl Statement: Organizations must implement continuous, real-time monitoring and alerting on current API usage against defined Salesforce limits to proactively prevent service disruptions.
Why tagged: Capacity and availability management controls expect monitoring that prevents service disruption from exhausted API quotas.
File Security
3 control(s) in this benchmark section.
SBS-FILE-001: Require Expiry Dates on Public Content Links
Moderate Source pageControl Statement: Organizations must ensure that Public Content links have an appropriate expiry date.
Why tagged: Information access restriction and secure handling of shared content support time-bounded external access.
SBS-FILE-002: Require Passwords on Public Content Links for Sensitive Content
High Source pageControl Statement: Organizations must ensure that Public Content links to sensitive content have a password.
Why tagged: Access control and information access restriction require protection of sensitive externally shared content.
SBS-FILE-003: Periodic Review and Cleanup of Public Content Links
Moderate Source pageControl Statement: Organizations must implement a recurring process to review all active Public Content links and remove or remediate links that are no longer required, lack appropriate controls, or were created outside of current policy.
Why tagged: Periodic review of externally shared content supports access governance and secure information handling.
Integrations
4 control(s) in this benchmark section.
SBS-INT-001: Enforce Governance of Browser Extensions Accessing Salesforce
Moderate Source pageControl Statement: Organizations must enforce a centrally managed mechanism that restricts which browser extensions are permitted to access Salesforce, and must not allow the use of unmanaged or uncontrolled extensions.
Why tagged: Endpoint security, secure configuration, and information access restriction support controlling browser extensions that can access Salesforce.
SBS-INT-002: Inventory and Justification of Remote Site Settings
Moderate Source pageControl Statement: Organizations must maintain an authoritative inventory of all Remote Site Settings and document a business justification for each endpoint approved for Apex HTTP callouts.
Why tagged: Information transfer and access governance controls support maintaining an authoritative inventory of approved outbound endpoints.
SBS-INT-003: Inventory and Justification of Named Credentials
Moderate Source pageControl Statement: Organizations must maintain an authoritative inventory of all Named Credentials and document a business justification for each external endpoint and authentication configuration approved for use in Salesforce.
Why tagged: Access governance and information transfer controls support maintaining an authoritative inventory of authenticated outbound connections.
SBS-INT-004: Retain API Total Usage Event Logs for 30 Days
High Source pageControl Statement: The organization must retain API Total Usage event log data (EventLogFile EventType=ApiTotalUsage) for at least the immediately preceding 30 days using Salesforce-native retention or automated external export and storage.
Description:
If the organization’s Salesforce does not provide at least 30 days of ApiTotalUsage EventLogFile availability in Salesforce, the organization must automatically export newly available ApiTotalUsage event log files at least once every 24 hours to an external log store that retains a minimum of 30 days of data.
Why tagged: Logging and evidence-retention controls require retained API activity logs for investigation and response.
OAuth Security
4 control(s) in this benchmark section.
SBS-OAUTH-001: Require Formal Installation of Connected Apps
Critical Source pageControl Statement: Organizations must formally install all connected apps used for OAuth authentication rather than relying on user-authorized OAuth connections.
Why tagged: Access control and secure authentication require formal governance of OAuth-enabled applications.
SBS-OAUTH-002: Require Profile or Permission Set Access Control for Connected Apps
Critical Source pageControl Statement: Organizations must control access to each formally installed connected app exclusively through assigned profiles or permission sets.
Why tagged: Access control and privileged restriction require connected app access to be explicitly assigned and governed.
SBS-OAUTH-003: Add Criticality Classification of OAuth-Enabled Connected Apps
High Source pageControl Statement: All OAuth-enabled Connected Apps must be recorded in an authoritative system of record and assigned a documented vendor criticality rating reflecting integration importance and data sensitivity.
Why tagged: Asset, supplier, and access governance controls support an authoritative inventory and criticality classification of connected applications.
SBS-OAUTH-004: Due Diligence Documentation for High-Risk Connected App Vendors
Moderate Source pageControl Statement: Organizations must review and retain available security documentation for all high-risk Connected App vendors and explicitly record any missing documentation as part of the vendor assessment.
Why tagged: Supplier relationship and security governance controls support documented due diligence for high-risk connected app vendors.
Security Configuration
2 control(s) in this benchmark section.
SBS-SECCONF-001: Establish a Salesforce Health Check Baseline
High Source pageControl Statement: Salesforce production orgs must define and maintain a Salesforce Health Check baseline—including Salesforce's native baseline XML or an equivalent customized baseline—and ensure it reflects the organization's intentional security configuration posture.
Why tagged: Secure configuration and change-management controls require a defined security baseline for platform settings.
SBS-SECCONF-002: Review and Remediate Salesforce Health Check Deviations
High Source pageControl Statement: Salesforce production orgs must periodically review Health Check results against the defined baseline and remediate deviations or formally document approved exceptions.
Why tagged: Secure configuration monitoring and change-management controls require periodic review of deviations from the approved security baseline.