Salesforce Security Review

The Approve Uninstalled Connected Apps permission allows users to bypass Connected App usage restrictions and self-authorize any OAuth application without administrator approval. This establishes an uncontrolled security boundary: users with this permission can grant external applications access to Salesforce data without oversight, enabling data exfiltration, unauthorized integrations, and potential account compromise. Unlike other permissions that require additional failures to exploit, this permission directly enables unauthorized third-party access the moment it is misassigned—making it a primary security boundary that must be tightly controlled.

1. Remove the Approve Uninstalled Connected Apps permission from any profile, permission set, or permission set group that lacks a documented justification or is assigned to end-users.
2. For any authorization that legitimately requires this permission (e.g., administrators or developers testing connected apps), add or update the rationale in the system of record to clearly justify the need and identify the specific role or use case.
3. Ensure that connected apps required for business operations are properly installed and allowlisted rather than relying on this permission for end-user access.
4. Reconcile and update the system of record to ensure complete and accurate inventory of all assignments of this permission.

1. Enumerate all profiles, permission sets, and permission set groups that include the Approve Uninstalled Connected Apps permission using Salesforce Setup, Metadata API, Tooling API, or an automated scanner.
2. Compare the enumerated list against the organization's designated system of record for this permission.
3. Verify that every profile, permission set, and permission set group granting "Approve Uninstalled Connected Apps" has a corresponding entry in the system of record.
4. Confirm that each entry includes:
   • A clear business or technical justification for requiring this permission,
   • Identification of the user role or persona (e.g., administrator, developer, integration manager),
   • Any applicable exception or approval documentation, and
   • Confirmation that the use case is limited to testing or managing connected app integrations.
5. Verify that the permission is not assigned to end-user profiles or permission sets intended for general business users.
6. Flag as noncompliant any authorizations lacking documentation, justification, or assigned to unauthorized user populations.

The Use Any API Client permission allows users to bypass API Access Control entirely, authorizing any OAuth-connected application without requiring it to be pre-vetted or allowlisted. This establishes an uncontrolled security boundary: users with this permission can grant data access to arbitrary external applications, enabling data exfiltration, unauthorized integrations, and potential account compromise without administrator oversight. Granting this permission to unauthorized personnel completely defeats the purpose of API Access Control, creating a direct path to unauthorized third-party access that requires no other control to fail.

1. Remove the Use Any API Client permission from any profile, permission set, or permission set group that lacks a documented justification or is assigned to end-users.
2. For any authorization that legitimately requires this permission (e.g., administrators or developers testing connected apps), add or update the rationale in the system of record to clearly justify the need and identify the specific role or use case.
3. Ensure that connected apps required for business operations are properly vetted and allowlisted rather than relying on this permission for end-user access.
4. Reconcile and update the system of record to ensure complete and accurate inventory of all assignments of this permission.

1. Enumerate all profiles, permission sets, and permission set groups that include the Use Any API Client permission using Salesforce Setup, Metadata API, Tooling API, or an automated scanner.
2. Compare the enumerated list against the organization's designated system of record for this permission.
3. Verify that every profile, permission set, and permission set group granting Use Any API Client has a corresponding entry in the system of record.
4. Confirm that each entry includes:
   • A clear business or technical justification for requiring this permission,
   • Identification of the user role or persona (e.g., administrator, developer, integration manager),
   • Any applicable exception or approval documentation, and
   • Confirmation that the use case is limited to testing or managing connected app integrations.
5. Verify that the permission is not assigned to end-user profiles or permission sets intended for general business users.
6. Flag as noncompliant any authorizations lacking documentation, justification, or assigned to unauthorized user populations.

Without the org-level SSO enforcement setting enabled, users can authenticate directly to Salesforce using local credentials—creating a parallel authentication path outside centralized identity management. This establishes an uncontrolled security boundary: password-based attacks (credential stuffing, phishing, brute force) can target Salesforce directly, enabling unauthorized access without requiring any other control to fail. Attackers bypass organizational identity controls, MFA policies, and session management enforced at the IdP layer. This setting is the primary technical control that establishes the SSO security boundary.

1. Navigate to Setup → Single Sign-On Settings.
2. Enable Disable login with Salesforce credentials.
3. Validate that SSO is properly configured and functional before enabling this setting to prevent lockout.
4. Ensure approved break-glass or administrative accounts have the "Is Single Sign-On Enabled" permission removed via their profiles or permission sets so they can still authenticate if needed.

1. Retrieve SingleSignOnSettings (part of SecuritySettings) via Metadata API or navigate to Setup → Single Sign-On Settings in the UI.
2. Verify that isLoginWithSalesforceCredentialsDisabled is set to true.
3. Flag the org if the setting is not enabled.

Without enforced multi-factor authentication, external users with substantial access to sensitive data can authenticate using only a password—establishing a single point of failure for the authentication boundary. External users present elevated credential risk due to weaker identity proofing, less organizational oversight, and exposure to consumer-grade phishing attacks. Attackers who compromise a single password through phishing, credential stuffing, or account takeover gain direct access to sensitive data without requiring any other control to fail. This creates an unprotected authentication path to high-value data that bypasses the defense-in-depth protections applied to internal users.

1. Apply the “Multi-Factor Authentication for User Interface Logins” permission through profiles or permission sets for all active external users with substantial access to sensitive data.
2. Configure suitable strong second-factor options in Setup -> Identity -> Identity Verification (e.g., authenticator app, FIDO2 security key).

1. Enumerate all active external human users with substantial access to sensitive data.
2. Validate that in-scope users have the “Multi-Factor Authentication for User Interface Logins” permission through profiles or permission sets.
3. Flag any in-scope users who lack the “Multi-Factor Authentication for User Interface Logins” permission.

When application logs capture sensitive data, attackers who compromise low-privilege accounts with Read access to log storage can exfiltrate credentials, PII, or regulated data without triggering access controls on the original source objects—transforming a logging framework into a data leakage vector. In regulated industries, a compromised administrator querying log objects can extract thousands of customer records in minutes, with the audit trail showing only "legitimate" queries. During breach investigations, logs become evidence of regulatory violations rather than forensic tools, triggering consent orders and significant financial penalties.

1. Implement mechanisms to prevent sensitive data from being written to logs:

   public class SecureLogger {
       public static void logInfo(String message, Map<String, Object> context) {
           // Sanitize context before logging
           Map<String, Object> sanitized = sanitizeContext(context);
           Logger.info(message, sanitized);
       }
       
       private static Map<String, Object> sanitizeContext(Map<String, Object> ctx) {
           Map<String, Object> result = new Map<String, Object>();
           for (String key : ctx.keySet()) {
               // Mask sensitive fields, log IDs instead of full records
               if (key.containsIgnoreCase('password') || 
                   key.containsIgnoreCase('token') || 
                   key.containsIgnoreCase('ssn')) {
                   result.put(key, '***REDACTED***');
               } else if (ctx.get(key) instanceof SObject) {
                   result.put(key, ((SObject)ctx.get(key)).Id);
               } else {
                   result.put(key, ctx.get(key));
               }
           }
           return result;
       }
   }
   

2. Audit existing log records in custom objects and purge Salesforce debug logs containing sensitive data.
3. Update logging calls to avoid capturing sensitive data:

   // BAD - logs full account with SSN field
   System.debug('Processing: ' + acc);
   Logger.info('Processing account', new Map<String, Object>{'account' => acc});
   
   // GOOD - logs only record ID
   System.debug('Processing account: ' + acc.Id);
   SecureLogger.logInfo('Processing account', new Map<String, Object>{
       'accountId' => acc.Id,
       'recordCount' => 1
   });
   

4. Consider implementing compensating controls such as automated testing that validates log outputs for sensitive data patterns, code review checks for logging security, or static analysis rules that detect common sensitive data exposure patterns.

1. Sample representative Apex classes from high-risk areas (customer-facing functionality, payment processing, authentication flows) to identify logging statements in both custom frameworks and System.debug() calls.
2. Examine log message construction to detect patterns that may capture the types of sensitive data listed above.
3. Query recent log records stored in custom objects and review Salesforce debug logs to inspect actual log content for sensitive data:
   • Search for patterns matching SSNs, credit card numbers, email addresses, phone numbers
   • Identify authentication tokens, session IDs, or API keys in log messages
   • Flag any log records containing regulated data or PII
4. Verify that mechanisms exist to prevent sensitive data from being logged (such as sanitization functions, code review checks, or automated validation).

When portal-exposed methods accept user-controlled parameters to determine record access, external users can manipulate these inputs to bypass intended access controls and exfiltrate unauthorized data. By iterating record IDs, modifying query filters, or injecting field names, attackers gain direct access to records beyond their sharing-based permissions—even when proper sharing keywords are declared. This vulnerability is especially severe in customer portal contexts where thousands of external users with adversarial intent can systematically enumerate organizational data. A single method accepting a record ID parameter from the frontend creates a SQL injection-equivalent vulnerability in the Salesforce trust model—allowing attackers to read, modify, or delete data without authentication or authorization checks, independent of any other security control failures. This constitutes a Critical boundary violation: unauthorized users access data they should never see, with no compensating controls required to fail.

1. Refactor portal-exposed methods to eliminate all parameters that control record access, query scope, or field selection.
2. Implement server-side logic that determines accessible records based on the running user's context:

   @AuraEnabled
   public static Account getMyAccount() {
       Id userId = UserInfo.getUserId();
       User currentUser = [SELECT ContactId FROM User WHERE Id = :userId];
       Contact portalContact = [SELECT AccountId FROM Contact WHERE Id = :currentUser.ContactId];
       return [SELECT Id, Name FROM Account WHERE Id = :portalContact.AccountId];
   }
   

3. For methods that must operate on specific records, validate ownership using UserRecordAccess before returning data:

   List<UserRecordAccess> access = [SELECT RecordId, HasReadAccess 
                                     FROM UserRecordAccess 
                                     WHERE UserId = :UserInfo.getUserId() 
                                     AND RecordId = :recordId];
   if (access.isEmpty() || !access[0].HasReadAccess) {
       throw new AuraHandledException('Access denied');
   }
   

4. Establish code review requirements that specifically check for parameter-based access control in portal-exposed methods.

1. Identify all Apex classes containing @AuraEnabled methods or other methods exposed to customer portal sites.
2. For each method, examine the parameter list to identify parameters of type Id, String, List<Id>, List<String>, Set<Id>, or Map<String, Object> that could control record access.
3. Review the method implementation to determine if parameters influence SOQL query construction (WHERE clauses, record IDs, field selection, relationship traversal).
4. Verify that methods derive record access from UserInfo.getUserId() or related user context rather than accepting frontend-supplied identifiers.
5. Conduct penetration testing by attempting to pass unauthorized record IDs or manipulated parameters from portal user sessions.
6. Flag any method that accepts user-supplied parameters controlling record access as noncompliant.

Guest users represent the highest-risk trust boundary in Salesforce portals—they are unauthenticated, have zero accountability, generate minimal audit trail, and operate with potential adversarial intent. When guest users are granted object permissions or can invoke custom Apex methods, attackers can systematically enumerate organizational data without even creating an account. Historical Salesforce security updates have repeatedly addressed guest user permission defaults because vendors consistently misconfigure this boundary. A single guest-accessible method that queries user records, cases, accounts, or custom objects creates a public API for data exfiltration accessible to anyone on the internet. This constitutes a Critical boundary violation: unauthenticated attackers access organizational data with no authentication required.

1. Remove all object-level permissions from guest user profiles except those explicitly required for authentication flows.
2. Audit and remove guest user access to any custom Apex methods that query or return organizational data.
3. For public data requirements (knowledge articles, case submission), implement service layer pattern:

   @AuraEnabled
   public static List<Knowledge__kav> getPublicArticles() {
       if (UserInfo.getUserType() == 'Guest') {
           // Allowlist-based, no parameters accepted
           return [SELECT Id, Title, Summary FROM Knowledge__kav 
                   WHERE PublicationStatus = 'Online' 
                   AND IsVisibleInPkb = true 
                   LIMIT 10];
       }
       throw new AuraHandledException('Access denied');
   }
   

4. Implement network-level rate limiting and CAPTCHA for guest-accessible endpoints.
5. Review Salesforce security updates and apply guest user permission restrictions from recent releases.

1. Identify all guest user profiles used by customer portal sites (typically named "Site Guest User" or similar).
2. Review object-level permissions for guest user profiles and verify that all business-related standard and custom objects have Read, Create, Edit, Delete permissions set to disabled.
3. Enumerate all custom Apex classes containing @AuraEnabled methods and verify that none are accessible to guest users (either by checking profile permissions or testing invocation from guest context).
4. For any guest-accessible functionality beyond authentication flows, verify implementation of service layer architecture with explicit access controls.
5. Test by accessing the portal without authentication and attempting to invoke Apex methods or query objects via built-in Lightning controllers.
6. Flag any guest user object permissions or method access as noncompliant.

Exposed Salesforce credentials in source repositories represent a direct path to unauthorized production access—a supply chain attack vector that bypasses all other access controls. Contractors, consultants, or any party with repository access can extract hardcoded tokens and authenticate directly to production orgs with the full permissions of the deployment identity. Attackers who compromise source control systems or CI/CD infrastructure gain immediate access to production Salesforce environments. Unlike other credential exposures, Salesforce access tokens often have broad administrative permissions and long validity periods, making them high-value targets. Organizations cannot detect this exposure through Salesforce audit logs alone—the attacker authenticates with valid credentials, and their activity appears legitimate.

1. Enable secret scanning on all repositories containing Salesforce code, metadata, or deployment configurations using platform-native tools or third-party secret scanning solutions.
2. Configure scanning rules to detect Salesforce-specific credential patterns in addition to general secrets.
3. Implement pre-commit hooks or CI checks that block commits containing detected secrets.
4. Immediately rotate any Salesforce access tokens, refresh tokens, or credentials that have been committed to version control—even if subsequently removed, as they persist in git history.
5. Migrate credential storage to secure secrets management solutions (e.g., CI/CD platform secrets, vault systems) and remove all hardcoded credentials from repositories.
6. Establish a periodic rotation schedule for Salesforce deployment credentials to limit the window of exposure if a secret is leaked.

1. Identify all repositories containing Salesforce metadata, SFDX projects, deployment scripts, or CI/CD pipeline configurations.
2. Verify that automated secret scanning is enabled on each repository—either through the source control platform's native capabilities (e.g., GitHub Secret Scanning, GitLab Secret Detection) or through third-party tooling.
3. Confirm that the scanning configuration includes patterns for Salesforce-specific secrets (access tokens, refresh tokens, consumer keys/secrets, session IDs).
4. Review scanning logs or dashboards to verify the tool is actively running and producing results.
5. Verify that detected secrets trigger alerts and block merges or deployments until remediated.
6. Flag noncompliance if any Salesforce-related repository lacks active secret scanning coverage.

Without formal installation, Connected Apps operate outside organizational control—inheriting security configuration from the external app developer rather than the Salesforce administrator. This establishes an unmanaged security boundary: refresh token lifetimes, session policies, and IP restrictions cannot be enforced, allowing tokens to persist indefinitely and enabling unauthorized access from any location. Attackers who compromise a user-authorized OAuth token gain persistent access that administrators cannot revoke or constrain through standard Connected App policies.

1. Formally install any connected app that appears only as a user-authorized OAuth connection.
2. Configure the installed connected app's policies, including refresh token and session security settings.
3. Remove the user-authorized OAuth connections that are now superseded by the installed connected app.

1. Enumerate all user-authorized OAuth connected apps via Setup or the Tooling/Metadata API.
2. Identify all connected apps that are not formally installed as managed or unmanaged connected apps.
3. Flag any connected app that is used but not formally installed as noncompliant.

Without explicit profile or permission set access control, Connected Apps may allow any user in the org to authenticate—bypassing the principle of least privilege and creating an uncontrolled access boundary. This enables unauthorized users to establish OAuth sessions with external systems, potentially exfiltrating data or performing actions beyond their intended scope. The lack of access scoping also eliminates audit visibility into who is authorized to use each integration, preventing detection of unauthorized access patterns.

1. For each connected app lacking profile or permission set access control, create or update profiles or permission sets to define which users are authorized to access the app.
2. Assign the appropriate profiles or permission sets to the connected app configuration.
3. Verify that no users can access the connected app without explicit authorization.

1. Enumerate all formally installed connected apps via Setup or the Metadata API.
2. For each installed connected app, verify that access is granted only through assigned profiles or permission sets.
3. Flag any connected app that lacks access scoping via profiles or permission sets as noncompliant.

Without a documented and enforced permission set model, organizations lose visibility into their authorization structure—accumulating ad hoc permission constructs created for one-time needs that are never reviewed or removed. This results in privilege sprawl, inconsistent access patterns, and inability to audit who has what access and why. Security teams cannot assess authorization posture, detect drift, or investigate access-related incidents when no authoritative model exists to compare against. The lack of continuous enforcement means unauthorized or excessive permissions can persist indefinitely without detection.

1. Update or deprecate noncompliant profiles, permission sets, and permission set groups to align with the documented permission set model.
2. Migrate users off legacy or misaligned authorization constructs.
3. Implement or enhance automated enforcement to ensure continuous alignment with the defined model.
4. Update the system-of-record documentation as the model changes.

1. Obtain the organization's documented permission set model from the designated system of record.
2. Enumerate all Profiles, Permission Sets, and Permission Set Groups using Salesforce Setup, Metadata API, or Tooling API.
3. Compare each enumerated item against the documented model to determine whether:
   • Its purpose or persona aligns with the model.
   • Its included permissions conform to the model's structure and boundaries.
   • Its naming and classification match the documented conventions.
4. Identify any profiles, permission sets, or permission set groups that do not conform to the model.
5. Verify that the organization has a process or automation that enforces model compliance in near real time (e.g., continuous scanning, pipelines, or governance workflows).

Without documented justification for API-enabled authorizations, organizations lose visibility into which users and systems can programmatically access Salesforce data at scale. The API Enabled permission enables large-scale data extraction, bulk modification, and automated operations—capabilities that create significant exposure when granted without oversight. Undocumented API access paths accumulate over time, preventing security teams from assessing data exfiltration risk, investigating suspicious API activity, or enforcing least privilege across automated access patterns.

1. Remove the API Enabled permission from any profile, permission set, or permission set group that lacks a documented justification and is not required for business operations.
2. For any authorization that legitimately requires API access, add or update the rationale in the system of record to clearly justify the need.
3. Reconcile and update the system of record to ensure complete and accurate inventory of all API-enabled authorizations.

1. Enumerate all profiles, permission sets, and permission set groups that include the API Enabled permission using Salesforce Setup, Metadata API, Tooling API, or an automated scanner.
2. Compare the enumerated list against the organization’s designated system of record for API-enabled authorizations.
3. Verify that every profile, permission set, and permission set group granting “API Enabled” has a corresponding entry in the system of record.
4. Confirm that each entry includes:
   • A clear business or technical justification for API access, and
   • Any applicable exception or approval documentation.
5. Flag as noncompliant any authorizations lacking documentation or justification.

Without documented justification for Super Admin–equivalent users, organizations lose visibility into who possesses unrestricted access to the entire Salesforce environment. These users can read and modify all data, manage user accounts, and alter the security posture of the org without oversight. Undocumented Super Admin access prevents security teams from assessing breach impact, investigating administrative actions, or maintaining accountability for the most sensitive operations. The inability to identify and justify these users also prevents effective access reviews and creates persistent exposure from forgotten or orphaned administrative accounts.

1. Remove one or more of the Super Admin–equivalent permissions from any user who does not have a documented business or technical justification.
2. For users who legitimately require this level of access, add or update rationale within the system of record.
3. Reassess user access to ensure alignment with least privilege, reducing broad permissions where narrower privileges are sufficient.

1. Enumerate all users who simultaneously possess the following permissions through any profile, permission set, or permission set group:
   • View All Data
   • Modify All Data
   • Manage Users
2. Compile a list of all users meeting the criteria for Super Admin–equivalent access.
3. Compare the list against the organization’s system of record.
4. Verify that each Super Admin–equivalent user has corresponding documentation that includes:
   • A clear business or technical justification for requiring this level of access, and
   • Any relevant exception or approval records.
5. Flag as noncompliant any users with Super Admin–equivalent access lacking documentation or justification.

Standard profiles are managed by Salesforce, not the organization—meaning Salesforce can enable permissions and object access on these profiles when features are released or platform updates occur without administrator approval. This creates an uncontrolled change vector: users assigned to standard profiles may gain new capabilities unexpectedly, bypassing the organization's authorization governance. Standard profiles are also overly permissive by default (e.g., "Standard User" grants "View Setup," "System Administrator" grants developer-level permissions), making it impossible to enforce least privilege. Without custom profiles, organizations cannot investigate authorization changes or maintain accountability for who approved which permissions.

1. Setup a custom profile for each standard profile that is used
2. Manage permissions and object access on these profiles to be compliant with the other controls of the SBS
3. Assign the new custom profiles to your active users, following the principle of "least privilege access"

1. Enumerate all human users that are "Active" (IsActive = true on the user flag)
2. Flag all users noncompliant that use a standard profile (IsCustom = false on the profile metadata)

Without a comprehensive inventory of non-human identities, organizations cannot detect, investigate, or respond to security incidents involving automated access. Non-human identities are frequently created for integrations or automation projects and then forgotten—accumulating as orphaned accounts with persistent credentials and elevated access. Security teams cannot assess which automated systems access Salesforce data, identify compromised integration credentials, or scope the impact of a vendor breach. This loss of visibility prevents effective governance of automated access and creates persistent security exposure from untracked machine accounts.

1. Query Salesforce to identify all potential non-human identities using the criteria in the audit procedure
2. For each identified identity, document: name, type (integration/bot/API), purpose, business owner, creation date
3. Establish a process to update the inventory when non-human identities are created, modified, or deactivated
4. Implement quarterly reviews of the inventory to identify and deactivate unused accounts
5. Store the inventory in an authoritative system of record accessible to security and compliance teams

1. Request the organization's inventory of non-human identities
2. Query Salesforce for all users where IsActive = true and any of the following conditions apply:
   • Username contains "integration", "api", "bot", "automation", or "service"
   • Profile name contains "Integration", "API", or similar indicators
   • User has "API Only User" permission enabled
   • User is associated with Einstein Bot or Flow automation
3. Compare the inventory to the query results to identify discrepancies
4. Verify the inventory includes: identity name, type, purpose, business owner, creation date, and last login date
5. Confirm the inventory is reviewed and updated at least quarterly

Without documented justification for broad non-human identity privileges, organizations lose visibility into which automated systems can bypass sharing rules or perform administrative operations. Non-human identities operate without human judgment, making over-privileged automation a high-impact target—compromised credentials can result in complete data extraction, system-wide configuration changes, or persistent backdoor access. Many non-human identities are granted excessive permissions during initial setup and never reviewed, creating long-lived security exposure that security teams cannot detect, investigate, or remediate without knowing which identities have which privileges and why.

1. For each non-human identity with broad privileges, evaluate whether the permission is genuinely required for the identity's function
2. Remove broad privileges that are not necessary; replace with more granular permissions where possible
3. For non-human identities that legitimately require broad privileges, document:
   • Specific business function requiring the permission
   • Why more granular permissions cannot satisfy the requirement
   • Business owner and technical owner
   • Approval from security or compliance team
4. Implement a formal approval process for granting broad privileges to non-human identities
5. Establish periodic review (at least annually) of all non-human identities with broad privileges

1. Using the non-human identity inventory from SBS-ACS-006, identify all non-human identities
2. For each non-human identity, query assigned permissions through profiles, permission sets, and permission set groups
3. Flag any non-human identity with one or more of the following permissions:
   • View All Data
   • Modify All Data
   • Manage Users
   • Author Apex
   • Customize Application
   • Any permission that bypasses sharing rules or grants administrative access
4. For each flagged identity, verify that documented business justification exists explaining why the permission is required
5. Confirm the justification was approved by appropriate stakeholders (security, compliance, or management)

Without enforced governance over access changes, organizations lose visibility and control over how privileges are granted and modified. Ad hoc access changes increase the risk of excessive privileges, unauthorized access, and violations of least-privilege principles. The absence of approval, justification, or auditability impairs incident investigation, undermines access reviews, and weakens compliance evidence for audits involving identity, access management, and change control.

1. Establish and document a formal governance process for access and authorization changes.
2. Require approval and business justification for all access modifications.
3. Ensure access changes are recorded in an auditable system of record.

1. Retrieve evidence of the organization's documented process governing access and authorization changes.
2. Identify access-related changes made during a representative review period.
3. For a sample of changes, verify:
   • An approval record exists prior to implementation
   • Business justification is documented
   • The change is traceable to an identifiable request
   • The implemented change is recorded in available audit or change history records
4. Identify any access changes lacking approval, justification, or auditability as noncompliant.

Salesforce debug logs are transient, size-limited, and automatically purged—making them unsuitable for forensic analysis or security investigations. Without persistent application logging, organizations cannot reliably reconstruct access patterns, detect anomalous behavior, or investigate security incidents after the fact. This impairs the ability to identify compromise, attribute malicious activity, or understand the scope of a breach—significantly extending attacker dwell time and reducing accountability for actions taken within the system.

1. Implement or install an Apex logging framework designed for persistent log storage.
2. Create or configure a custom object (or equivalent durable storage) to store log records.
3. Update Apex code to route log events through the framework.
4. Train engineering and security teams to use persistent logs instead of debug logs for investigations.

1. Review the Salesforce org for the presence of an Apex logging framework implemented as one or more Apex classes dedicated to log generation and persistence.
2. Verify that the framework writes logs to durable storage, such as a custom object purpose-built for log retention.
3. Confirm that operational and security investigations rely on this persistent logging mechanism rather than Salesforce debug logs.
4. Inspect recent log records to ensure the framework is actively capturing runtime events.

Long Text Area fields often contain unstructured, user-entered information that may include sensitive personal data. Without a detection mechanism, regulated data accumulates in unknown locations—obstructing compliance with GDPR Right to Erasure, CCPA deletion requests, and similar privacy obligations. During a security incident, the inability to identify which fields contain personal information makes it impossible to accurately assess exposure, determine the scope of compromised records, or fulfill breach notification requirements. This governance gap significantly impairs incident response and creates ongoing regulatory liability.

1. Deploy or configure a tool, script, or process capable of analyzing the contents of LTA fields for regulated data.
2. Ensure scans run continuously or on a recurring schedule.
3. Confirm all applicable fields across all objects are included.
4. Document the scanning process and store execution evidence for audit support.

1. Identify all Long Text Area fields using Salesforce metadata.
2. Determine whether the organization has a mechanism that scans the contents of each LTA field for regulated data.
3. Confirm that scanning occurs continuously or on a defined recurring schedule.
4. Review scan logs, detection outputs, or configuration details to verify that the mechanism is operational.
5. Validate that all LTA fields across all objects are included in scope.
6. Determine compliance based on whether such a mechanism exists and is functioning.

Without reliable backups and tested restoration procedures, organizations cannot recover from accidental deletion, malicious data destruction, configuration corruption, or ransomware-like events. This impairs incident response, business continuity, and the ability to validate data integrity after security events or outages.

1. Implement or configure a backup solution for Salesforce data and metadata.
2. Define backup frequency, retention, and storage protections.
3. Execute and document restoration tests on the defined schedule.
4. Update recovery procedures based on test results.

1. Obtain the documented backup and recovery policy covering Salesforce data and metadata.
2. Verify that backups are performed on a defined schedule and retained per policy.
3. Review evidence of a completed restoration test within the defined testing interval.
4. Confirm that backup storage is protected with appropriate access controls.

Without field history tracking on sensitive fields, unauthorized or accidental changes cannot be reliably detected or investigated. This reduces auditability, impairs incident response, and weakens accountability for changes to regulated or high-impact data.

1. Enable Field History Tracking for all listed sensitive fields.
2. Update the sensitive-field list as schemas evolve.
3. Re-verify tracking coverage after changes.

1. Obtain the organization’s documented list of sensitive fields and in-scope objects.
2. Enumerate Field History Tracking settings for those objects.
3. Verify that each listed sensitive field has Field History Tracking enabled.
4. Flag any sensitive field without tracking.

Without a designated deployment identity, organizations cannot reliably attribute production changes—any administrator can deploy metadata, making it impossible to distinguish authorized CI/CD deployments from unauthorized manual changes. This loss of provenance prevents security teams from detecting unauthorized modifications, investigating configuration drift, or determining whether a change was part of an approved release. Attackers or malicious insiders can make direct production changes that blend into legitimate administrative activity, and incident responders cannot reconstruct the timeline of configuration changes during a breach investigation.

1. Create or identify a dedicated deployment identity.
2. Reconfigure CI/CD pipelines, release management tooling, and automated deployment scripts to authenticate exclusively with the deployment identity.
3. Revoke deployment permissions from all human users.
4. Re-deploy any metadata last deployed by a human user to restore provenance.

1. Identify the user account designated as the deployment identity.
2. Enumerate all recent metadata deployments using tooling such as Deployment Status, Metadata API logs, or audit logs.
3. Verify that all deployments were executed by the designated deployment identity.
4. Flag any metadata deployment performed by a human user or non-deployment identity.

Without an explicit list of high-risk metadata types, organizations cannot define or enforce deployment governance boundaries—leaving critical configuration categories (Apex code, authentication settings, outbound connectivity, permissions) open to uncontrolled direct production editing. Security teams cannot distinguish between metadata that requires strict deployment controls and metadata that can be safely edited manually, resulting in inconsistent governance and gaps in change attribution. The absence of a defined list also prevents effective monitoring (SBS-DEP-003), as there is no baseline to compare against when detecting unauthorized changes.

1. Adopt the SBS baseline list of prohibited direct-in-production metadata changes.
2. Add any organization-specific items or exceptions as needed.
3. Remove modify permissions for these metadata types from all human users.
4. Ensure all future changes to listed metadata types are performed exclusively by the deployment identity.

1. Obtain the organization's documented list of high-risk metadata types prohibited from direct production editing.
2. Confirm that the list, at minimum, includes all SBS baseline categories.
3. Review the list for any documented exceptions and verify they are formally approved.
4. Verify that only the deployment identity has modify permissions for metadata types on the list.

Without monitoring for unauthorized metadata changes, organizations cannot detect when high-risk configuration is modified outside the approved deployment process—allowing malicious changes, accidental drift, or insider threats to persist undetected. Security teams lose the ability to identify unauthorized modifications to authentication settings, permission structures, Apex code, or outbound connectivity until a breach or incident reveals the gap. This impairs detection, investigation, and response capabilities for configuration-related security events, extending attacker dwell time and preventing timely remediation of unauthorized changes.

1. Implement a monitoring mechanism capable of identifying modifications to high-risk metadata and attributing them to the responsible user. Acceptable approaches include:
   • Manual periodic review of the Salesforce Setup Audit Trail,
   • Exporting audit logs for review,
   • Scheduled API or CLI queries comparing metadata changes,
   • Custom scripts,
   • Vendor-based monitoring tools.
2. Ensure the monitoring method covers all high-risk metadata types listed in the organization’s defined prohibited-direct-edit list.
3. Define a repeatable review interval and assign responsibility for conducting the review.
4. Document the monitoring approach and maintain records of reviews and findings.

1. Interview system owners to identify the monitoring method(s) used for detecting changes to high-risk metadata.
2. Review documentation describing how the monitoring process works—whether manual log review, automated scripts, API queries, CLI workflows, scheduled exports, or vendor tools.
3. Verify that the monitoring process includes:
   • Coverage of all high-risk metadata types defined by the organization and required by SBS-DEP-002.
   • A review interval appropriate to the organization's change-management expectations (e.g., daily, weekly, or aligned with release cycles).
   • A method for identifying the user who performed each change.
4. Examine historical monitoring records or logs to confirm the process has been performed consistently.
5. Flag noncompliance if no monitoring system exists or if the system cannot detect unauthorized human modifications to high-risk metadata.

Without a source-driven deployment process, organizations lose the verifiable audit trail that connects production configuration to approved changes—making it impossible to determine what changed, when, by whom, and whether it was authorized. Security teams cannot investigate configuration-related incidents, restore known-good state during outages, or attribute changes during forensic analysis. Manual production changes bypass code review, testing, and approval workflows, enabling unauthorized, accidental, or malicious modifications to security-sensitive settings without accountability or detection.

1. Establish and maintain a centralized version control repository for Salesforce metadata.
2. Implement or enforce an automated deployment pipeline that deploys changes exclusively from version control.
3. Restrict direct production changes for metadata types that support programmatic deployment.
4. Document and periodically review any required manual production changes for metadata types lacking deployment support.

1. Identify the organization’s standard deployment process and designated deployment identity as defined in SBS-CHG-001.
2. Review recent production metadata changes and their associated deployment records.
3. Verify that changes deployable through Salesforce’s programmatic deployment mechanisms originated from centralized version control.
4. Confirm that any manual production changes are limited to metadata types that Salesforce does not support for programmatic deployment.
5. Flag any manually applied changes that could have been deployed through the source-driven process.

Salesforce CLI token files stored on local workstations represent a persistent credential exposure risk. If a laptop is stolen, reassigned without proper cleanup, or compromised by malware, attackers can extract token files that provide direct access to Salesforce orgs—including production environments. With the default Connected App configuration, these tokens never expire, giving attackers indefinite access that persists even after the original user's password is changed or their account is deactivated. The attack surface expands with each org a developer authenticates to, as token files accumulate credentials to sandboxes, Dev Hubs, and production orgs. Organizations cannot detect this credential theft through Salesforce audit logs because the attacker authenticates with valid tokens.

1. Determine whether to use the default "Salesforce CLI" Connected App or create a dedicated Connected App for CLI authentication.
2. If using the default app:
   • From Setup, navigate to Connected Apps OAuth Usage.
   • Locate "Salesforce CLI" and click Install (if not already installed), then Edit Policies.
   • Set Refresh Token Policy to "Expire refresh token after: 90 Days" (or less).
   • Set Session Policies Timeout Value to "15 minutes" (or less).
3. If creating a dedicated Connected App:
   • Create a new Connected App with OAuth enabled and appropriate callback URL.
   • Configure refresh token expiry to 90 days or less and access token timeout to 15 minutes or less.
   • Distribute the Consumer Key to developers and require use of --client-id flag.
4. Communicate to developers that they will need to re-authenticate periodically when refresh tokens expire.
5. Consider implementing compensating controls to protect locally stored token files, such as:
   • Requiring full disk encryption (FileVault, BitLocker) on developer workstations.
   • Enabling remote wipe capability for managed devices.
   • Including Salesforce CLI token file cleanup in device offboarding procedures.
   • Training developers to run sf org logout --all before returning or transferring devices.

1. From Setup, navigate to Connected Apps OAuth Usage (or Apps → Connected Apps → Connected Apps OAuth Usage).
2. Identify the Connected App(s) used for Salesforce CLI authentication—either the default "Salesforce CLI" app or a custom Connected App.
3. Review the OAuth Policies for each CLI-related Connected App:
   • Verify that Refresh Token Policy is set to "Expire refresh token after" with a value of 90 days or less.
   • Verify that Session Policies Timeout Value is set to 15 minutes or less.
4. If a custom Connected App is used, verify that developers are instructed to use the --client-id flag when authenticating.
5. Flag noncompliance if any CLI-related Connected App has tokens set to never expire or exceeds the maximum allowed durations.

Without retained API Total Usage logs, organizations lose visibility into REST, SOAP, and Bulk API activity—including user identity, connected app, client IP, resource accessed, and status codes. This materially degrades the ability to detect anomalous API behavior, investigate security incidents, attribute unauthorized access, and determine the scope of potential breaches. The absence of this visibility creates a significant gap in incident detection and response capabilities.

1. If the organization has only 1-day ApiTotalUsage EventLogFile availability in Salesforce, implement an automated daily export that downloads newly available ApiTotalUsage log files and stores them externally for at least 30 days.
2. If the organization uses Salesforce-native retention, ensure the configured retention period for Event Log Files is not less than 30 days.
3. Restrict access to the retained logs (Salesforce-native or external) to authorized personnel and designated service identities.

1. Determine whether the organization relies on Salesforce-native retention (Event Monitoring/Shield/Event Monitoring add-on) or an external log store as the system of record for ApiTotalUsage EventLogFile data.
2. If the organization relies on Salesforce-native retention, verify that EventLogFile data is retained for at least 30 days (for example, confirm the org is entitled to and configured for Event Log File retention that is at least 30 days and can retrieve ApiTotalUsage EventLogFile data within the preceding 30-day window).
3. If the organization relies on an external log store (including all orgs with only 1-day ApiTotalUsage availability in Salesforce):

• Verify an automated process exists that retrieves EventLogFile entries where EventType='ApiTotalUsage' and downloads the associated log files at least once every 24 hours.
• Inspect job schedules/run history and confirm successful executions covering at least the last 30 days (no missed days).
• From the external log store, retrieve ApiTotalUsage logs for (a) the oldest day in the preceding 30-day window and (b) the most recent day, and confirm both are accessible and attributable to the organization.
• Verify access to the external log store is restricted to authorized roles and service identities responsible for monitoring and investigations.

Without a complete inventory and criticality classification, organizations lose visibility into their third-party integration landscape—preventing effective risk assessment, prioritization of security controls, and governance of external system connectivity. Security teams cannot identify which integrations access sensitive data, scope the impact of a vendor compromise, or respond effectively to incidents involving Connected Apps. This impairs detection, investigation, and response capabilities for integration-related security events.

1. Add any missing OAuth-enabled Connected Apps to the system of record.
2. Document and assign a vendor criticality rating to each Connected App based on operational importance and data sensitivity.
3. Implement a recurring process to synchronize Connected App changes with the system of record.

1. Retrieve a list of all Connected Apps with active OAuth configurations from Salesforce Setup.
2. Retrieve the organization's authoritative system of record for integration and vendor management.
3. Compare the Salesforce Connected App list to the system of record and confirm every OAuth-enabled Connected App appears in the inventory.
4. Verify each listed Connected App has an assigned vendor criticality rating documented in the system of record.
5. Flag any apps missing from the inventory or lacking a documented criticality rating as noncompliant.

Without a defined Health Check baseline, organizations have no authoritative reference for what their security configuration should be—making it impossible to detect drift, evaluate deviations, or determine whether current settings reflect intentional decisions or accumulated neglect. Security teams cannot assess configuration-related risk, investigate whether settings were deliberately changed, or demonstrate compliance with security requirements. The absence of a baseline also prevents effective use of Health Check deviation monitoring (SBS-SECCONF-002), as there is no standard to measure against.

1. Create or select a Health Check baseline (Salesforce default, SBS-recommended baseline, or a custom-defined XML).
2. Upload the baseline XML into Setup → Health Check.
3. Document ownership of the baseline and establish a process for periodic review and updates.
4. Communicate the baseline's purpose and implications to system owners and security stakeholders.

1. Navigate to Setup → Health Check and confirm that a baseline template is uploaded and active.
2. Review the XML baseline directly (via UI or API) to verify that the baseline exists and contains intentional values rather than defaults left unexamined.
3. Interview administrators to confirm the baseline was deliberately chosen or customized and is understood as the organization's configuration standard.
4. If the organization lacks a baseline, flag the control as noncompliant.

Without periodic review and remediation of Health Check deviations, configuration drift accumulates undetected—weakening security posture over time as settings diverge from the intended baseline. Security teams cannot identify when critical platform settings (authentication, session management, content security) have been changed or misconfigured, preventing timely response to emerging vulnerabilities. Unaddressed deviations may persist indefinitely, creating exploitable gaps that remain invisible until a breach or audit reveals the exposure.

1. Establish a recurring review process using any reliable method, including:
   • Salesforce Health Check UI,
   • API exports,
   • CLI automation,
   • Scheduled scripts,
   • Vendor tooling.
2. Assign ownership for conducting the review and maintaining documentation.
3. Review current deviations and either remediate them or document exceptions.
4. Implement tracking to ensure deviations are remediated or re-reviewed in future cycles.

1. Interview system owners to identify the established Health Check review process and review interval (e.g., monthly, quarterly).
2. Examine evidence of recent Health Check reviews, such as documented review artifacts, exported reports, tickets, changes, or exception records.
3. Verify that deviations were:
   • Remediated within the review window, or
   • Documented as exceptions with clear justification and approval.
4. Confirm that the review process is repeatable, assigned to an owner, and actually followed.
5. Flag noncompliance if:
   • No review process exists,
   • No review evidence can be produced, or
   • Deviations occur without remediation or exception documentation.

Access review is the foundational control for preventing privilege creep, detecting unauthorized access, and remediating execessive permissions. Without periodic review, users accumulate access over time -- permissions granted for past roles remain after job changes, access added for temporary projects becomes permanent, and no formal mechanism ensures access remains least-privilege. Periodic formal recertification by business stakeholders ensures that access governance remains aligned with organizational reality. Documentation of review creates an audit trail and ensures accountability. Regular remediation prevents drift and maintains the integrity of the permission set model defined in SBS-ACS-001.

1. If no access review process exists, establish documented policy including frequency, reviewers, scope, and remediation SLAs.
2. Conduct an initial comprehensive access review of all active users, with business unit or department ownership of sign-off.
3. Identify and remediate all access determined excessive, unauthorized, or inappropriate during the initial review.
4. Implement a system of record (spreadsheet, governance tool, or integrated platform) to track reviews, findings, and remediation.
5. Schedule recurring access reviews at minimum annual frequency, with quarterly reviews for sensitive roles or high-risk data.
6. Document the review process, including templates, stakeholder roles, and escalation procedures.
7. Establish accountability for reviewers and tie review completion to performance management or audit requirements.

1. Understand the organization's dcoumented access review policy, including:
   • Defined frequency and review cycle
   • Designated reviewers and escalation path
   • Intended coverage scope and access types included
   • Expected remediation timeframe for findings
   • System of record for tracking review activity and findings.
2. Assess the recency and regularity of access review execution. Locate the most recent completed acccess review cycle and evaluate whether it aligns with the organization's stated review frequency.
3. Examine a representative sample of access review documentation to asssess consistency of execution:
   • Evidence of review and approval by the designated stakeholder
   • Documentation of review date and scope
   • Any findings, exceptions, or questions raised during the review
   • Appropriateness of sample size relative to the organization's user population and complexity
4. For any access identified as excessive, unauthorized, or not recertified:
   • Assess whether the finding was documented
   • Evaluate what remediation action was taken or whether exceptions were formally approved
   • Compare remediation timing against the defined SLA
5. Assess whether the organization maintains a traceable system of record that documents:
   • Who reviewed what access
   • When the review occurred
   • What was approved or questioned
   • What remediation was required and its completion status
6. Evaluate whether the access review process adequately addresses the organization's primary access constructs, which may include the following types of assignment:
   • User profiles
   • Permission sets
   • Permission set groups
   • Role and role hierarchies
   • Public group
   • Queues
   • Sales Territories
   • Delegated administration or elevated permissions

Users permitted to bypass SSO represent exceptions to centralized identity governance. Without formal documentation and approval, these accounts can proliferate unnoticed—reducing visibility into access patterns and undermining audit readiness. However, this control provides assurance and governance rather than establishing a security boundary. Undocumented exceptions increase operational risk and reduce audit readiness but require credential compromise for direct security impact.

1. Create or update a formal inventory documenting all SSO-bypass users with their business justification, owner, and approval date.
2. For any undocumented or unjustified users: assign the "Is Single Sign-On Enabled" permission via their profile or permission sets to remove SSO-bypass capability.
3. Ensure all documented exceptions adhere to least-privilege access and strong authentication controls.
4. Establish periodic (e.g., quarterly) review of all SSO-bypass accounts.

1. Query all user records to identify users who do not have the "Is Single Sign-On Enabled" (PermissionsIsSsoEnabled) permission assigned through their profile or permission sets.
2. Verify each identified user appears in the approved system-of-record inventory with documented business justification, owner, and approval.
3. Confirm each exception is authorized for administrative or break-glass purposes only.
4. Validate that these accounts follow strong local authentication controls (e.g., strong password policies, MFA if applicable).
5. Flag any user without documented approval.
6. (Optional) Download API Total Usage logs (EventLogFile - ApiTotalUsage, available in free tier of Event Monitoring) to monitor SSO bypass account activity:
   • Filter API activity by users identified as SSO bypass accounts.
   • Review frequency and timing of API calls to verify usage aligns with documented break-glass purposes.
   • Flag any SSO bypass accounts with regular or unexpected API activity for review against documented justifications.

Overly broad login IP ranges effectively disable network-based access controls, allowing authentication from any location on the internet. However, exploitation requires credentials to be compromised first—this control provides defense-in-depth rather than establishing a primary security boundary. When authentication controls (SBS-AUTH-001) are enforced, IP restrictions serve as an additional layer that limits the blast radius of credential compromise.

1. Remove any profile login IP ranges that effectively grant unrestricted global access.
2. Replace them with IP ranges that correspond to approved corporate networks, office locations, VPN ingress points, or other authorized infrastructure.
3. Validate that updated network restrictions do not block legitimate access paths and that users can authenticate through sanctioned networks.
4. Establish an internal governance process to review and approve all future additions of profile login IP ranges.

1. Retrieve all profile login IP ranges via Setup → Profiles → Login IP Ranges or by querying the Profile metadata (loginIpRanges field) using the Metadata API.
2. For each profile, enumerate all configured login IP ranges.
3. Identify any ranges that:
   • Cover the entire IPv4 space, or
   • Represent effectively unrestricted access (e.g., 0.0.0.0–255.255.255.255, 1.1.1.1–255.255.255.255, or similar patterns).
4. Confirm that all IP ranges align with organizational security policy and defined network boundaries.
5. Flag any profile with an impermissible or overly broad range.
6. Download API Total Usage logs (EventLogFile - ApiTotalUsage, available in free tier of Event Monitoring) to validate IP restrictions are effective:
   • Extract unique CLIENT_IP values from recent API activity.
   • Compare against documented approved organizational network ranges.
   • Identify any new or unexpected IP addresses making API calls.
   • Cross-reference unusual IPs with profile assignments to identify potential policy gaps.

Without mandatory peer review, a single developer—whether compromised, malicious, or simply mistaken—can introduce insecure or flawed code directly into the deployment pipeline. This eliminates shared oversight of changes to sensitive business logic, allowing vulnerabilities, backdoors, or destructive changes to reach production without independent human verification before deployment.

1. Update branch protection rules to require peer review before merge.
2. Train developers on the peer review workflow, including security checks such as identifying sensitive data in logging statements.
3. Block direct commits to production-bound branches.

1. Inspect source control settings to confirm merge rules require peer review on production-bound branches.
2. Review merge history or representative pull requests to verify peer approvals were recorded.
3. Confirm that peer review processes include security checks such as verifying logging statements do not expose sensitive data.
4. Flag any repositories or branches that allow merging without peer approval.

Without enforced static code analysis, known vulnerability patterns in Apex and LWC—such as SOQL injection, insecure data exposure, and improper access control—may enter production undetected. This increases the likelihood of exploitable flaws persisting in deployed code, creating potential vectors for data breaches or unauthorized access that human reviewers may not catch.

1. Integrate static code analysis into the CI/CD pipeline for all production-bound branches.
2. Enable Apex and LWC security rulesets within the scanning tool.
3. Configure pipelines to block merges when static analysis fails.

1. Inspect CI/CD pipeline configuration to confirm a static code analysis step runs before merges.
2. Verify the SAST tool includes security rulesets for Apex and Lightning Web Components.
3. Review pipeline logs from representative merges to ensure scans executed and passed.
4. Flag pipelines or branches missing enforced pre-merge scanning.

Without centralized governance over browser extensions, malicious or cloned extensions—increasingly common with AI-generated code—can harvest session tokens, exfiltrate data, and execute unauthorized operations within authenticated Salesforce sessions. However, this control provides governance and defense-in-depth rather than establishing a Salesforce-native security boundary: exploitation requires a malicious extension to be installed and an authenticated session to exist. Other controls (SSO, session management) still provide protection, and this governance mechanism operates outside Salesforce via MDM or browser management.

1. Implement a centrally managed browser or device management solution capable of enforcing extension restrictions (e.g., Chrome Browser Cloud Management, Intune, Jamf, or GPO-based controls).
2. Define and apply an allow-list or blocklist policy governing which extensions are permitted to interact with Salesforce.
3. Remove or disable any unapproved browser extensions from managed devices.
4. Apply enforcement policies to all corporate-managed devices accessing Salesforce.

1. Request evidence of a browser-extension governance mechanism applied to user devices (e.g., Chrome Browser Cloud Management, Intune configuration profile, Jamf configuration profile, Active Directory GPO, or equivalent).
2. Require a screenshot, exported policy file, or screen capture demonstrating that extension controls are active and enforceable (e.g., an allow-list or blocklist configuration for Chrome extensions).
3. Verify that the mechanism explicitly restricts installation or execution of unapproved extensions that can access Salesforce domains.
4. Flag the organization as noncompliant if no enforceable governance mechanism exists or if extension governance is based solely on policy, awareness, or voluntary user behavior.
5. Download API Total Usage logs (EventLogFile - ApiTotalUsage, available in free tier of Event Monitoring) and analyze for indicators of unauthorized browser extension activity:
   • Review USER_AGENT field for patterns indicating browser extensions (e.g., extension identifiers, non-standard user agents).
   • Identify API call patterns characteristic of auto-refresh extensions (e.g., Inspector Reloader) such as regular-interval repeated requests.
   • Flag any anomalous patterns for investigation against approved extension inventory.

Without a documented inventory and justification for Named Credentials, undocumented or unjustified configurations may expose the organization to data leakage, unauthorized integrations, or reliance on insecure or untrusted endpoints. However, this control provides governance documentation rather than detection or prevention capability: it supports audit readiness and informed decision-making about authenticated external connections, but other controls are required to detect or prevent actual misuse of approved credentials.

1. Add any undocumented Named Credentials to the system of record.
2. Document a valid business justification for each Named Credential.
3. Remove, disable, or reconfigure any Named Credentials that cannot be justified or that reference untrusted endpoints.
4. Establish a recurring reconciliation process to ensure Named Credentials remain fully inventoried and justified.

1. Enumerate all Named Credentials using Salesforce Setup, Metadata API, Tooling API, or Connect REST API.
2. Retrieve the organization’s system of record for approved external endpoints and integration credentials.
3. Compare the Salesforce list to the system of record to confirm all Named Credentials are documented.
4. Verify that each documented Named Credential includes:
   • The external endpoint URL
   • The authentication type (named principal or per-user)
   • The business justification for the integration
5. Flag any Named Credentials missing from the inventory or lacking justification as noncompliant.

Without documented due diligence for high-risk vendors, organizations may onboard integrations without understanding the vendor's security posture, data handling practices, or contractual obligations. This increases the likelihood of undiscovered risks but does not directly enable unauthorized access—other controls (SBS-OAUTH-001, SBS-OAUTH-002) still govern the technical security boundary. Missing documentation primarily impacts audit readiness, risk assessment accuracy, and the organization's ability to make informed decisions about vendor relationships.

1. Collect and store all required documentation for each high-risk vendor.
2. Where documentation does not exist, record this absence in the vendor assessment.
3. Update the vendor management process to ensure ongoing due diligence for high-risk vendors.

1. Retrieve the list of Connected App vendors classified as high-risk from the organization’s system of record.
2. For each high-risk vendor, verify that the following documents, where available, are stored in the designated repository:
   • Terms of use
   • Privacy policy
   • Trust center or security overview
   • Published information security guidelines
3. Confirm that any missing documentation is explicitly recorded as unavailable in the vendor assessment.
4. Flag any high-risk vendor lacking required documentation or missing explicit acknowledgment of unavailable documents as noncompliant.