Salesforce SOC 2 Compliance: A Complete Guide

Salesforce SOC 2 compliance comes in two parts. Salesforce has independent SOC 2 reports for its own services, but those reports stop at the platform, so the controls inside your org are yours to prove.

That split catches teams out at audit time. An auditor may rely on Salesforce's report for the platform, then ask who approved last month's production deployment.

Is Salesforce SOC 2 compliant?

Yes, for the services it runs: the Salesforce Services SOC 2 report covers IT general controls and "availability, confidentiality and security of customer data." Its latest period runs from November 1, 2025 to April 30, 2026.

Not every product is in scope, though. Salesforce's Security, Privacy and Architecture document, published October 20, 2026, lists services excluded from its SOC 1, SOC 2 and SOC 3 audits, including DevOps Center (now Lifecycle Center).

SOC 2 isn't a certificate, either. The American Institute of Certified Public Accountants (AICPA) describes it as "an examination performed by a licensed, independent CPA under the AICPA Attestation Standards."

Who can perform a SOC 2 audit?

By the official definition, SOC 2 is "an examination performed by a licensed, independent CPA under the AICPA Attestation Standards." Software tools and consultants may gather evidence, but the opinion in the report comes from the auditor.

Service organizations get audited because customers and business partners often request a SOC 2 report. It gives them the information they need to assess and address the risks of handing a service to a vendor.

How do you get Salesforce's SOC 2 report?

Salesforce posts its reports on the SOC 2 page of its compliance site. It says they "give assurance over control environments as they relate to the retrieval, storage, processing, and transfer of data."

Getting the right one takes three steps:

1. Log in to the compliance site, since each report is marked "Login to download."
2. Pick the report that covers your services: since June 2026, Corporate, first-party and Hyperforce services share one Salesforce Services report. Some products, such as Hyperforce on Google Cloud, have their own.
3. Check that its period overlaps your own audit window, and look for a bridge (gap) letter where one is listed.

What are the SOC 2 Trust Services Criteria?

SOC 2 examinations are measured against the 2017 Trust Services Criteria (TSC), with points of focus revised in 2022. The five trust services criteria cover security, availability, processing integrity, confidentiality and privacy.

A report doesn't have to cover all five, and Salesforce's own report covers three: security, availability and confidentiality. The table below maps each criterion to the Salesforce controls and evidence an auditor may ask about.

In October 2026 the AICPA proposed 2027 criteria, with new points of focus on AI governance, model monitoring, prompt manipulation and data poisoning. Comments are open until January 15, 2027, and if approved, the updated framework would apply to engagements beginning on or after December 31, 2027.

What's the difference between SOC 2 Type 1 and Type 2?

A Type 1 report is a point in time view: it looks at whether controls are designed properly "as of a specified date," says the Journal of Accountancy. A Type 2 report, often written Type II, adds an opinion on the operating effectiveness of those controls over a specified period.

A Type 2 (Type II) report also includes a description of the auditor's tests of controls and results. So for your own SOC 2 program, each of your internal controls should leave evidence each time it runs.

SOC 3 covers the same subject matter in a less detailed report whose use isn't restricted, while SOC 1 covers controls relevant to financial reporting. SOC 2 reports are generally restricted, and Salesforce keeps its copies behind a login.

What does your team own under the shared responsibility model?

Salesforce's shared responsibility model says "customers are responsible for protecting their own data, configurations, and access rights." Its Security, Privacy and Architecture documentation adds that its services include "a variety of configurable security controls" for customers to set up.

On its own side, Salesforce says it maintains security incident management policies and procedures. It also commits to notify affected customers of any unauthorized disclosure of their Customer Data that it becomes aware of.

The table below sketches how that split plays out in a typical org, with Salesforce's side on the left and your own evidence on the right. Our post on the Salesforce shared responsibility model goes deeper.

Which Salesforce monitoring logs help in a SOC 2 audit?

Three Salesforce tools record the activity an auditor is likely to sample:

• Setup Audit Trail records setup changes, with the 20 most recent shown on screen. You can download the past 180 days, and Salesforce says "After 180 days, setup entity records are deleted."
• Event Monitoring does log deployments: its MetadataApiOpEventLog object "stores details of Metadata API retrieval and deployment requests." With Shield or the Event Monitoring Add-on, event log files are kept for 1 year by default.
• Field Audit Trail can keep field history for up to 200 fields per object indefinitely, as our Field Audit Trail guide explains.

What these logs don't show is why a change happened. They can't tell an auditor who approved it, which ticket asked for it or which tests passed, and our audit trail compliance guide covers how to close that gap.

What are common SOC 2 compliance gaps in Salesforce?

Teams that download Salesforce's report often find these gaps once the auditor starts sampling. Each one sits on the customer side of the shared model.

Permissions tend to grow over time, which is how permission sprawl turns up in access reviews. To limit unauthorized access, Salesforce points to MFA, login IP restrictions and permission sets that give people "exactly the permissions they need to do their jobs."

Sandboxes are the other common miss, so use data masking before real customer records land in a test org. If you've scoped privacy in, our guide to data privacy and security in Salesforce covers the wider rules for personal information.

How does Salesforce DevOps help with SOC 2 compliance?

An auditor testing your change controls will want to know who changed what, when and who approved it. A disciplined release process records those answers as it ships work, so you're not rebuilding months of history before an audit.

Picture an auditor who picks five production changes at random. For each one, they'll want the business reason, the approver, the test results and the deployment record.

With controls built into the pipeline, that request is one report. Without them, it's days of searching tickets, chat threads and email.

These are the controls that produce that evidence:

• Version control that records every metadata change and its author.
• Approval captured before deployment, with a timestamp and the approver's name.
• A policy that stops the author of a change from approving it for production.
• Automated tests and static code analysis on every promotion, with the results kept.
• A documented emergency-change process that still leaves a record.
• Rollback, with the rollback itself logged.

A control only counts if it runs every time and can't be skipped under deadline pressure. That's the version an auditor can test, and it's the idea behind continuous compliance.

Availability evidence needs the same habit. Back up data and metadata on a schedule, and test restores as part of your backup and recovery strategy.

How Flosum supports SOC 2 evidence

Flosum offers three deployment options: Salesforce-native, Flosum-hosted cloud and customer-hosted. The Salesforce-native option is a managed package installed in your org.

The two hosted options run Flosum's Cloud Apps on AWS that Flosum manages, or on a virtual machine you own. Flosum's hosted services are audited by third parties every six months.

Flosum holds its own SOC 2 Type II report, covering both its Cloud and Native products, available under NDA. With the customer-hosted model, though, those certifications don't extend to the systems you run, so plan your audit scope around the model you pick.

Flosum DevOps keeps change history beyond Salesforce's native 180-day Setup Audit Trail window. It adds approvals and one-click rollback, so the sampled-change request above becomes a report.

FAQs

Book a demo to see how Flosum DevOps records approvals, tests and deployments for your next SOC 2 audit.