Salesforce Trust Center is Salesforce's public transparency portal for platform availability, security, and compliance information. It publishes real-time service status, incident detail, maintenance schedules, and downloadable audit certifications across Salesforce products.
It answers one question faster than anything else: is this problem Salesforce’s or ours?
That question matters because Salesforce orgs hold sensitive customer data, financial records, and business-critical workflows. When performance degrades or an auditor asks for a current SOC 2 report, teams need an authoritative answer in minutes rather than a support ticket and a three-day wait.
This guide covers what Salesforce Trust Center is, what it publishes, how to access it, what changed with the 2026 launch of My Trust Center, and where its responsibilities end.
Does Salesforce Have a Trust Center?
Yes. Salesforce Trust Center is the company's official transparency portal, available at trust.salesforce.com without a login.
The site is organized around four areas reachable from its top navigation: Status, Security, Compliance, and Availability. Status covers live service health and incidents. Security and Compliance cover Salesforce’s own controls, certifications, and audit documentation.
Salesforce also runs an authenticated version called My Trust Center at my.trust.salesforce.com, which narrows the same information down to your specific orgs and products.
Takeaway: the public site answers questions about Salesforce. The authenticated site answers questions about your orgs.
What Is the Salesforce Trust Center?
Salesforce Trust Center is Salesforce’s public-facing transparency portal covering platform availability, security practices, and compliance documentation. Salesforce describes trust as its number one value, and the portal is where that claim becomes auditable.
Four groups use it regularly. Admins and IT check service status during incidents. Security teams reference platform controls. Compliance teams download certifications during audits. Procurement and vendor management teams verify sub-processors and data center locations.
The portal deliberately covers Salesforce’s side of the shared responsibility model. It documents what Salesforce operates and secures. It reports nothing about what happens inside your org.
Takeaway: Trust Center is a reporting surface for Salesforce’s platform, not a management console for your environment.
Key Features of Salesforce Trust Center at a Glance
The portal bundles several distinct capabilities across a few different subdomains. The table below summarizes what each one provides and where it lives, before the sections that follow go deeper.
Takeaway: most of the day-to-day value concentrates in two places, the status dashboard during incidents and the compliance portal during audits.
Trust Status Dashboard: Real-Time Service Availability
The Trust Status dashboard at status.salesforce.com displays current operational status for Salesforce products including Sales, Service, Industries, Agentforce, MuleSoft, Tableau, Slack, Commerce, Marketing, and Heroku.
To use it, you first need your instance name. Find it in Setup under Company Information in the Instance field, or enter your My Domain into the search box at the top of status.salesforce.com.
Salesforce publishes five availability statuses, each with a defined meaning and its own color.
The dashboard also separates incidents affecting a single instance from incidents affecting a product across all instances. Instance-specific incidents surface only for customers on that instance.
That distinction tells you immediately whether to investigate your own configuration or wait for Salesforce to resolve a platform issue.
Incident detail pages carry an incident ID, the affected services and instances, start and end times, running updates, and a root cause analysis after resolution where one is published.
Salesforce advises that if you are experiencing an issue with the core service that has lasted more than 10 minutes and nothing appears on the status site, you should contact Salesforce Support.
Takeaway: check the status page before you troubleshoot, but do not treat a green board as proof that nothing is wrong.
Trust Status Notification Configuration
Salesforce offers email notifications for incidents and maintenance, configured through the Trust notification user guide. Subscriptions can be filtered by instance, by service, and by event type.
Enterprise teams managing several orgs usually tier subscriptions by environment rather than routing everything to one inbox:
- Production instances route to an incident management platform such as PagerDuty or ServiceNow for on-call response
- Sandbox instances route to a distribution list for review during business hours
- Development instances receive notifications only for the most severe statuses
Many teams then automate email-to-ticket creation so platform incidents land in the same queue as everything else, with ticket priority mapped to the reported status.
One caveat matters for anyone planning ahead: legacy Trust notification subscriptions do not carry over to My Trust Center automatically. Teams that migrate have to re-subscribe.
Takeaway: tiering by environment is what stops alert fatigue from burying the notifications that actually matter.
Compliance Documentation Portal: Centralized Audit Resources
The compliance portal at compliance.salesforce.com centralizes certifications, audit reports, and attestations. Most documents require authentication with Salesforce credentials before you can download them.
This replaces the older process of requesting documentation through support tickets, which could take days. The portal also publishes sub-processor lists, data center and infrastructure documentation, and service coverage documents.
Service coverage documents matter more than most teams realize. They list exactly which products fall inside each certification’s scope, and anything not listed falls outside it.
Takeaway: download the coverage document alongside the certificate, because auditors ask which services the certificate actually covers.
Audit and Attestation Standards
Audit standards provide third-party verification of Salesforce’s security controls and operational processes. The portal publishes the major ones.
Two details are easy to miss. SOC 2 Type II reports cover a defined operating period, so compliance teams need to confirm the report period overlaps their audit period, and download two reports when an audit period spans cycles.
SOC 2 reports also list complementary user entity controls, which are the security responsibilities that fall to you. Salesforce controls physical data center access. You control authentication settings, session timeouts, and IP restrictions. Auditors expect evidence for both sides.
Certifications also do not extend to third-party AppExchange packages installed in your org. Those carry their own certifications, or none at all.
Takeaway: a Salesforce certificate covers Salesforce’s services, not everything running inside your org.
Regulatory Compliance Frameworks
Beyond audit standards, the portal publishes documentation supporting specific regulatory regimes. Each one splits responsibility between Salesforce and the customer.
HIPAA deserves particular attention because it is the framework teams most often misread. Executing a Business Associate Agreement does not make an org compliant on its own.
Customers handling protected health information are generally expected to encrypt data at rest, maintain audit trails covering access to that data, configure session security and login IP ranges, and require multi-factor authentication. Salesforce supplies the infrastructure attestation. You supply evidence of your own configuration.
Takeaway: every framework here splits responsibility, and Trust Center documents only Salesforce’s half.
Salesforce My Trust Center: What Changed in 2026
Salesforce launched My Trust Center, an authenticated and personalized version of the Trust experience, renaming the earlier Personalized Trust beta in the Spring 2026 release. It is now generally available at my.trust.salesforce.com.
The public site reports at instance level, which means subscribers receive alerts for every product on an instance whether they use it or not. My Trust Center filters down to the tenants and products actually assigned to you, which is the main reason to move.
It adds capabilities the public site does not have:
- One full year of historical event data for your tenants
- Patch release information published four to five days before the patch goes live
- Patch releases and maintenance windows shown alongside incidents
- Tenant-level notification subscriptions filtered by event type
- Coverage extending to sandbox orgs
Salesforce has been explicit that this is a transition rather than a switch. The public Trust and Status sites run in parallel for now, because not every product has migrated, access for non-licensed users is still being built, and customers need time to move subscriptions and integrations.
Two migration items need planning. Legacy Trust notification subscriptions do not transfer automatically. Automated monitoring built against legacy Trust APIs will eventually need to point at My Trust Center instead.
Takeaway: keep using the public site, but start moving subscriptions and integrations now rather than during the eventual sunset.
How to Access Salesforce Trust Center
The public portal requires no account. The compliance documents and the personalized experience both require authentication.
Access the public Trust site
- Go to trust.salesforce.com.
- Use the top navigation to reach Status, Security, Compliance, or Availability.
- On status.salesforce.com, enter your My Domain in the search box to identify your instance, or find it in Setup under Company Information.
- Click an instance or an incident to see detail, affected services, and the maintenance calendar.
Download compliance documentation
- Go to compliance.salesforce.com.
- Authenticate with your Salesforce credentials.
- Locate the certification or report you need and confirm its coverage period.
- Download the document along with the matching service coverage document.
Set up My Trust Center
- Go to my.trust.salesforce.com and register using your Trailblazer account.
- Review Upcoming Maintenance for planned work over the next 90 days.
- Select Tenants to see the orgs assigned to you, then View Details for past, current, and future events.
- Open Subscriptions, click Subscribe to Tenant, and choose the event types you want to receive.
Takeaway: public status needs no login, compliance documents need Salesforce credentials, and personalized status needs a Trailblazer account.
Trust Center's Role in Security Operations
Trust Center sits on Salesforce’s side of the shared responsibility model. Salesforce operates and secures the platform, and Trust Center is where it reports on that work. Customers configure access, data protection, and application controls, and Trust Center reports nothing about those.
In practice the dashboard functions as a triage gate. During any incident, checking status first separates platform problems from org problems before anyone starts investigating configuration.
A green board is not proof of platform health, though. Salesforce may not have detected or posted an emerging incident yet. Corroborate with other signals: whether other customers on your instance report the same symptoms, what your own Event Monitoring data shows, and whether the issue spans multiple unrelated orgs.
If every org on an instance shows identical symptoms at the same time, that pattern points to a platform incident regardless of what the board displays.
Takeaway: use Trust Status to rule causes out quickly, not to declare the platform healthy.
Common Trust Center Usage Scenarios
These four scenarios cover most of the situations where teams reach for Trust Center, and they show the decision logic in each case.
Scenario 1: Mass login failures. Users across the org cannot log in. Check the status dashboard for your instance. A Service Disruption listing authentication among the affected services confirms a platform issue. Communicate the incident ID and estimated resolution to users, monitor the incident page, and hold off on internal authentication troubleshooting.
Scenario 2: Slow report performance. Dashboards that used to load in seconds now take far longer. The status board shows everything available with no active incidents. That points to an org-level cause. Investigate query performance, selective filters, record volumes and data skew, and scheduled report subscriptions running at peak hours.
Scenario 3: Intermittent API failures. Integration monitoring shows an elevated error rate against a previously stable baseline. The status board shows Service Degradation for your instance, meaning the service is reachable but impaired. Add or increase retry logic, extend timeouts temporarily, and monitor for the resolution notice.
Scenario 4: Audit documentation request. An auditor asks for evidence of SOC 2 coverage across a specific period. Authenticate at compliance.salesforce.com, open the SOC 2 section, confirm the report period covers the audit window, then download the report and the service coverage document. If the audit period spans two reporting cycles, download both reports.
Takeaway: three of these four scenarios end with Trust Center telling you the problem is yours, which is exactly the value it provides.
Where Trust Center's Role Ends
Trust Center reports on Salesforce’s platform. It does not manage security inside your org.
It cannot tell you whether a specific user accessed customer records outside business hours, whether anyone changed profile permissions in the last 30 days, or whether last night’s deployment introduced a misconfiguration. Those are org-layer questions, and they need org-layer tools.
The table below maps Trust Center against the Salesforce products that answer those questions.
Takeaway: Trust Center tells you what Salesforce did. Everything else on that list tells you what your users and your releases did.
Trust Center vs. the Salesforce Known Issues Site
Known Issues is a separate Salesforce site, now folded into Salesforce Help, where Salesforce publishes confirmed software defects with their current status and any documented workarounds.
The distinction is simple. Trust Center covers service availability and incidents, meaning something that was working has stopped. Known Issues covers defects, meaning something behaves incorrectly by design flaw rather than by outage.
During troubleshooting, check Trust Center first for an active incident. If the board is clear and one specific feature is misbehaving, search Known Issues before opening a support case.
Takeaway: outages live on Trust Center, defects live on Known Issues, and confusing the two costs troubleshooting time.
Critical Limitations
Trust Center publishes incident-level information, not aggregate performance metrics. It does not report mean time to resolution, service level objective compliance, or comparative uptime trends.
Salesforce does not publish aggregate uptime figures publicly because service level commitments vary by contract, edition, and negotiated terms. Those commitments live in individual Master Subscription Agreements rather than in public documentation.
Customers who need documented uptime guarantees for compliance or vendor management should raise it with their account team, ideally as part of a renewal conversation.
Programmatic access is another gap. A community-known Trust Status API endpoint exists, but it is not officially supported, so integrations built on it can break without notice. Salesforce has also signaled that legacy Trust APIs will eventually need to point at My Trust Center.
Finally, the public documentation does not cover enterprise integration patterns or escalation workflow design. Teams that need that guidance generally go through Premier Success or a technical account manager.
Takeaway: treat Trust Center as an authoritative source for what happened, not as a metrics platform or a stable API.
Using Trust Center Effectively
The teams that get the most out of Trust Center treat it as a step inside existing workflows rather than a site to visit when something breaks.
Two habits do most of the work. Make the status check the first line of every incident runbook, and maintain a mapping document that translates common audit requests into specific compliance portal documents.
Takeaway: Trust Center is an informational resource, and its value comes from wiring it into processes you already run.
Make Enterprise Data Governance Part of Your Salesforce Culture
Three points are worth carrying out of this guide. Trust Center is Salesforce’s transparency portal for platform availability, security, and compliance. My Trust Center is the authenticated, org-specific version now generally available. And everything happening inside your org sits outside both.
That last point is where the exposure lives. Trust Center confirms that Salesforce’s infrastructure remains secure and certified. It says nothing about whether last week’s release introduced a permission change nobody reviewed, or whether configuration drift has quietly widened access between audits.
Closing that gap takes deployment governance: version control over metadata, approval gates before changes reach production, and audit trails that outlast native retention windows. Event Monitoring covers user activity inside the org. Deployment controls cover the changes that alter what users can do in the first place.
Flosum is an end-to-end enterprise DevSecOps platform purpose-built for Salesforce, with three deployment options (Salesforce-native, cloud, and customer-hosted) so teams can match governance to their architecture rather than the other way round. Request a demo to see how deployment governance complements the platform transparency Trust Center already provides.
Frequently Asked Questions (FAQ)
Thank you for subscribing
