Salesforce SOC 2 compliance is a shared job: Salesforce holds its own SOC 2 reports for its services, and you are responsible for how your org is configured and used. Running on Salesforce does not make your organization SOC 2 compliant. A SOC 2 audit looks at your controls, and for most organizations the Salesforce part of that is access, change control, monitoring and offboarding.
This checklist covers what to ask Salesforce for, and what to check in your own org. It is general guidance written by Salesforce practitioners. It is not audit, legal or compliance advice, and your auditor decides what evidence they need.
What SOC 2 is
The AICPA describes a SOC 2 report as an examination of controls at a service organization, based on management's description of its system, and relevant to security, availability, processing integrity, confidentiality or privacy (AICPA, SOC 2 reporting guide, checked November 2026). Customers and business partners often ask a service organization for its SOC 2 report because they need to know how its controls work.
Three points that clear up most confusion:
- SOC 2 is an audit report, not a certificate you buy or a checklist you pass. An independent CPA firm examines the controls and writes a report.
- It applies to a service organization. If your nonprofit or health organization provides a service to others, a customer or funder may ask you for one. If you only consume services, you more often need to collect your vendors' reports.
- Scope is chosen. The five areas (security, availability, processing integrity, confidentiality, privacy) are not all required in every report. Which ones are included is part of the engagement.
A report may be a Type 2, which includes tests of controls and their results, as shown in the AICPA's illustrative example (AICPA, illustrative SOC 2 Type 2 report, checked November 2026). Reports also name the period they cover, so check the dates when you read one.
What Salesforce covers, and what you cover
Salesforce publishes compliance documents, including SOC 2 reports for its services, on its Compliance site (Salesforce Compliance, checked November 2026). Reports are listed by service, such as individual products and infrastructure, so find the ones for the products you actually use. Availability varies: some reports can be downloaded and others are available on request through your account team.
Salesforce's shared responsibility model divides the work. Its architect guidance says Salesforce secures the platform's infrastructure and certifications, while customers secure what they configure and build on top of it, including access, custom code and data governance (Salesforce Architects, Trust, checked November 2026).
In short: Salesforce's report tells your auditor about the platform. It does not tell them whether your users have the right access.
The checklist
Treat each item as a question you should be able to answer with evidence.
1. Vendor evidence
- Have we downloaded or requested the SOC 2 reports for each Salesforce product we use?
- Have we noted the reporting period and reviewed any exceptions the report lists?
- Do we have a record of which date we reviewed them and who did?
- For AppExchange apps and integrations that touch Salesforce data, do we hold their reports or equivalent assurance?
2. User access
- Is there a current list of active users, with a business owner for each?
- Is access granted through an approved request, and can we show it?
- Do we follow least privilege? Salesforce's guidance is to grant the minimum access necessary for each user, integration and automated process.
- Who holds powerful permissions such as View All Data, Modify All Data, Manage Users and Export Reports? See how to find over-permissioned users.
- Are shared and generic logins eliminated?
3. Authentication
- Is multi-factor authentication required for everyone?
- Is single sign-on used where you have a central directory?
- Are API and integration users documented, limited and monitored?
4. Joiners, movers and leavers
- Can we show how a new user's access was approved?
- Is access reviewed when someone changes role?
- How quickly are leavers deactivated, and can we prove it? Our offboarding checklist is a starting point. Automating the process can help, as explained in SCIM provisioning for Salesforce.
- Do we perform periodic access reviews, and do we keep the results?
5. Data access and sharing
- Are org-wide defaults documented and the most restrictive that works? See sharing model best practices.
- Can we explain each sharing rule in one sentence?
- Is sensitive data limited to the people who need it?
6. Change management
- Are changes made in a sandbox, reviewed and then deployed, rather than edited live in production?
- Is there a record of who approved and released each change?
- Are admin and developer permissions limited and reviewed?
7. Logging and monitoring
- What activity records do we keep, and for how long? Free event logs for Login and Logout have one day of retention in supported editions, according to Salesforce's Trailhead (Trailhead, Event Monitoring, checked November 2026). If your needs go beyond that, see whether Salesforce Shield is worth it.
- Who reviews the logs, and how often?
- Is there a process for investigating and recording a suspicious event?
8. Policies and documentation
- Is there a written access control policy, and does the org match it?
- Are roles, profiles, permission sets and sharing documented in plain language?
- Is there an incident response plan that names Salesforce as a system in scope?
9. Data protection
- Do we know where sensitive data lives in the org?
- Do we have a backup and recovery approach, and have we tested it?
- Have we decided whether any field needs encryption or longer audit history?
Evidence is what auditors ask for
Many teams do the right things but cannot show them. Build a simple evidence folder. For each control, keep the policy, a dated screenshot or export, who approved it and the date reviewed. Doing this quarterly is far easier than rebuilding it the week before an audit.
Where Troppus can help
We are a Salesforce consultancy. We are not an audit firm and we do not hold or issue SOC 2 reports, so we can't say whether you pass. What we do is look at the Salesforce side. Our Apex Security Check analyzes access risk and finds over-permissioning, Onboard360 automates the user lifecycle with an audit trail, and Security Framework Design provides templates for roles, profiles and sharing rules with audit-ready documentation. See the products page.
Frequently asked questions
Is Salesforce SOC 2 compliant?
Salesforce publishes SOC 2 reports for its services on its Compliance site. That covers Salesforce's controls over its platform. It does not make your own organization compliant.
Do we need our own SOC 2 report?
Only if you provide a service to others who ask for it, such as a customer or partner. If you only use vendors, you mostly need to collect and review their reports. Ask your counsel or auditor what applies.
What is the difference between Type 1 and Type 2?
A Type 2 report includes tests of controls and the results over a period. Ask your auditor to explain how a Type 1 differs for your situation. Customers often ask for Type 2.
Which Salesforce settings matter most for SOC 2?
Access control (permissions and sharing), authentication, offboarding, change management and logging. These are also the areas where your own configuration decides the outcome.
Can an admin prepare for this without extra products?
Much of it, yes. Salesforce says customers manage platform security settings and that many responsibilities can be handled by admins without add-ons. Some needs, such as long activity retention, may require extra licenses.
Start with a baseline
If you are preparing for a customer security review, a funder question or an audit, an access and sharing review is the fastest way to find the gaps. Book a free Salesforce health check.