Salesforce Health Cloud is deployed in regulated healthcare environments on the strength of a single fact: Salesforce signs a Business Associate Agreement. This is true. It is also incomplete. The BAA that Salesforce offers covers Health Cloud as deployed in Salesforce's HIPAA-eligible service configuration — a configuration that requires specific licensing, specific feature enablement, and specific configuration decisions that are not the default state of a new Health Cloud org.
What the Salesforce BAA Covers
Salesforce's Health Cloud HIPAA-eligible configuration covers the core Health Cloud data model (Person Accounts, Patient relationships, Care Plans, Care Gaps, Medication records) when those objects are stored within the HIPAA-eligible service boundary. The BAA covers Salesforce Shield Platform Encryption when enabled — Shield is the product that provides field-level encryption for PHI at rest within the Salesforce platform. The BAA covers standard Salesforce security features: role-based access controls, IP whitelisting, two-factor authentication, and audit trail.
Shield Platform Encryption is not included in standard Health Cloud licensing. It is a separately licensed add-on. Health Cloud without Shield stores PHI in Salesforce's standard encrypted-at-rest infrastructure, which uses Salesforce-controlled keys. Shield enables customer-managed encryption keys and field-level encryption with a tenant-controlled key management service. For highly sensitive data (mental health records, HIV status, substance abuse records), customer-managed keys via Shield are the defensible HIPAA position.
The Salesforce BAA explicitly excludes: any data processed by Einstein AI features (including Einstein Prediction Builder and Einstein Next Best Action), data processed by third-party AppExchange packages unless those packages maintain their own BAAs, data transmitted to or from Salesforce via integrations not covered by a separate BAA, and any sandbox or non-production environment unless the BAA specifically includes them. PHI should not be used in sandbox environments — use synthetic data.
Event Monitoring and Audit Trail
HIPAA's audit control requirement (§164.312(b)) requires the ability to record and examine activity in information systems that contain PHI. Salesforce's standard Audit Trail captures administrative configuration changes but not every user access to PHI records. Event Monitoring — available as a separately licensed feature — provides detailed event logs including login events, report exports, API calls, and individual record views. For HIPAA compliance, Event Monitoring is effectively required. Event Monitoring logs must be exported and retained for the HIPAA-applicable period.
The Sharing Model and Minimum Necessary
HIPAA's minimum necessary standard (§164.502(b)) requires that access to PHI be limited to the minimum necessary for the purpose of the use or disclosure. Salesforce's sharing model — roles, profiles, permission sets, and sharing rules — is the mechanism that implements minimum necessary in Health Cloud. Common failure patterns: using the "View All Data" profile permission for roles that do not need it, creating overly broad sharing rules that expose all records of a given type to all users, and failing to restrict the access of integration users that connect Health Cloud to external systems.
Third-Party AppExchange Packages
Before installing any AppExchange package in a HIPAA-covered Health Cloud org, the vendor must provide a signed BAA, documented evidence that their infrastructure is HIPAA-compliant, and a data processing agreement that specifies how they handle PHI. Installing a package without these in place is a HIPAA violation — the package vendor becomes a business associate upon accessing PHI, and operating without a BAA is a direct violation of the BAA requirement.
- License Shield Platform Encryption for any Health Cloud org that stores PHI — this is a separate license, not included in standard Health Cloud
- License Event Monitoring to satisfy the HIPAA audit control requirement — standard Audit Trail is insufficient
- Design the sharing model against the minimum necessary standard before go-live, not after
- Prohibit PHI in sandbox environments — enforce this with automated data masking for any sandbox refresh
- Require BAAs from all AppExchange vendors before installation — enforce this as a procurement gate, not a post-installation review
- Map every Einstein AI feature against the BAA exclusions before enabling — excluded features must not process PHI
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.