Skip to main content

SOC 2 mapping

SOC 2 is the audit most enterprise-tier SaaS vendors and managed-service providers carry. For a Salesforce-deployed app, the SOC 2 audit asks whether the technical controls protecting the org meet the Trust Services Criteria. This page maps the criteria most relevant to a Salesforce deployment onto the Vulkro detectors that produce evidence for them.

For the non-Salesforce half of a SOC 2 audit (web app, API, mobile, cloud infrastructure), see the general-scanner SOC 2 page.

Run it​

vulkro-sf scan ./force-app --compliance soc2
vulkro-sf scan ./force-app --compliance-pack soc2 -o soc2-readiness.html

The HTML report is grouped by Trust Service Criterion and prints a PASS / FAIL / NOT EVALUATED verdict per control row.

Trust Services Criteria covered​

CriterionTitleVulkro detector(s) that feed it
CC6.1Logical access provisioningprofiles-permsets (over-privilege, dormant admins), security-settings (password policy, MFA via session settings)
CC6.2User access removalprofiles-permsets (dormant admin detection)
CC6.3Least privilegeprofiles-permsets (over-privilege detection: ModifyAllData, AuthorApex, CustomizeApplication)
CC6.6External-system accessconnected-apps (OAuth posture, Drift / Gainsight class), named-credentials
CC6.7Sensitive data transmissionsecurity-settings (requireHttps enforcement), connected-apps (OAuth scope review)
CC6.8Malicious code preventiondetectors/apex (crypto misuse, hardcoded secrets), org-packages (beta package warning)
CC7.1Vulnerability detectionThe whole scan. This is what vulkro-sf does.
CC8.1Change managementCI/CD integrations (PR-gate evidence, baseline snapshots)
CC9.1Risk mitigationsecurity-settings (hardening posture), connected-apps (third-party data flow risk)
C1.1Confidential information at restpii-map (sensitive SObject inventory)

Per-criterion detail​

CC6.1 Logical access provisioning​

The Trust Service Criterion: the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

In a Salesforce org, that means three things: profiles and permission sets do not over-grant, MFA is enforced, and password policy is set to something more than the platform minimum.

Vulkro emits findings for:

  • Profile or permission set carrying any of ModifyAllData, AuthorApex, or CustomizeApplication outside the System Administrator profile.
  • Session settings with MFA absent or weak.
  • Password policy below the documented baseline (length, complexity, history, expiration).

CC6.2 User access removal​

The criterion: prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users; access is removed when no longer required.

Vulkro flags dormant admin profiles: profiles with admin-equivalent permission grants that have not been assigned to an active user in a period exceeding the documented threshold. The full org-side audit needs a live org pull (the org-status connector) to see actual user assignments.

CC6.3 Least privilege​

The criterion: the entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.

Vulkro's profile / permission set detector emits over-privilege findings any time a non-admin profile carries an admin-equivalent grant.

CC6.6 External-system access​

The criterion: the entity implements logical access security measures to protect against threats from sources outside its system boundaries.

For a Salesforce org, the system-boundary surface is Connected Apps, Named Credentials, and (increasingly) Agentforce / Einstein 1 integrations. Vulkro covers:

  • Connected App OAuth scope review (the "Full access" scope is flagged).
  • Connected Apps in the Drift / Gainsight breach class (third-party OAuth integrations with the same posture as the 2024-25 ShinyHunters incidents).
  • Named Credentials with cleartext (http://) endpoints.
  • Named Credential secrets in metadata (credential leaks committed to source).

CC6.7 Sensitive data transmission​

The criterion: the entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal.

Vulkro checks:

  • SecuritySettings.requireHttps enforcement on every login route and Site / Experience Cloud surface.
  • Connected App callback URLs on https://.
  • Outbound callouts to non-TLS endpoints.

CC6.8 Malicious code prevention​

The criterion: the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

Vulkro emits findings for:

  • Crypto misuse in Apex (deprecated algorithms, weak modes, insecure-random sources).
  • Hardcoded credentials in Apex source.
  • Org-status warnings for installed beta managed packages (a beta package is functionally unreviewed code running in the org with whatever access the installer granted).

CC7.1 Vulnerability detection​

The criterion: to meet its objectives, the entity uses detection and monitoring procedures to identify changes in configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

This is what vulkro-sf does. The whole scan is the evidence for this control. The SARIF output is the artifact.

CC8.1 Change management​

The criterion: the entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

The CI/CD integration is the evidence here. A PR-gate that runs vulkro-sf on every change and fails the build on new findings is the auditor-facing artifact for change management. See CI/CD integration for the GitHub Actions wiring and the baseline-snapshot pattern.

C1.1 Confidential information at rest​

The criterion: the entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.

The Salesforce-shaped version of this control is "where does PHI / PCI / PII actually live in the org?" Vulkro's PII map detector emits a sensitive-SObject inventory with field-level annotations, by default covering the standard PII fields (Email, Phone, Address__c, SSN__c) and surfacing custom-field naming patterns that suggest sensitivity.

Audit evidence: what to hand the auditor​

The artifacts an auditor wants:

  1. The SARIF file from each scan. Every finding has a finding ID, severity, file / line, framework tags, and the scan's UTC timestamp. SARIF is the OASIS standard format auditors accept directly.
  2. The compliance-pack HTML report. vulkro-sf scan --compliance-pack soc2 -o soc2-readiness.html produces a single self-contained HTML file. Save as PDF for the audit package.
  3. The baseline file. vulkro-sf scan --baseline baseline.json is the dated snapshot. Each new scan diffs against it. The baseline is the "as of date X" evidence row in the SOC 2 system description.
  4. The CI workflow log. GitHub Actions / GitLab CI runs of vulkro-sf are the change-management evidence (CC8.1).

What's NOT covered​

A scanner does not produce evidence for the organizational TSCs. SOC 2 also asks the auditor to evaluate:

  • CC1 Control Environment: the entity demonstrates a commitment to integrity and ethical values, board independence, organizational structure, and accountability.
  • CC2 Communication and Information: the entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
  • CC3 Risk Assessment: the entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
  • CC4 Monitoring Activities: the entity selects, develops, and performs ongoing or separate evaluations.
  • CC5 Control Activities: the entity selects and develops control activities and general controls over technology.

These need written policy, signed contracts, evidence of training, and documented governance. Vulkro does not produce them. A SOC 2 Type II audit needs both the technical evidence Vulkro emits and the organizational evidence your operations team builds.