HIPAA-Compliant Salesforce: What Health Cloud Covers and What It Doesn’t

A HIPAA-compliant Salesforce org is possible, but no Salesforce product makes an organization compliant on its own. Salesforce signs a business associate agreement for a specific list of services, and Salesforce Health Cloud adds healthcare data models and workflows on top of the platform. Everything else, from access controls and encryption choices to risk analysis and staff training, stays with the healthcare organization. That split is where most compliance gaps appear.

Many healthcare teams assume that buying Health Cloud settles the HIPAA question. It doesn’t. Health Cloud is a product for managing patients, members, and care teams, and it runs on the same platform as Sales Cloud and Service Cloud. The compliance picture depends on the signed agreement, the services it names, the way the org is configured, and the apps and integrations connected to it. This guide explains what each layer covers, where the gaps sit, and what a healthcare organization has to do itself.

TL;DR

•        No software is HIPAA compliant by itself. Compliance depends on a signed business associate agreement plus your own safeguards, policies, and configuration.

•        Salesforce’s BAA covers named services, including Sales Cloud, Service Cloud, Health Cloud, Experience Cloud, Salesforce Shield, and Marketing Cloud Engagement. Health Cloud isn’t the only covered service.

•        Some features are excluded or restricted, such as the Lightning Platform Discover feature, Marketing Cloud Einstein features in Growth and Advanced, and several Tableau products.

•        Salesforce requires customers to encrypt PHI in transit and, where within their control, at rest. Salesforce Shield is the usual tool for encryption at rest, event monitoring, and long-term field history.

•        AI features need extra care. Salesforce bars using Einstein and Agentforce services for diagnosis and requires Data Masking in the Einstein Trust Layer for covered use.

•        AppExchange apps and third-party integrations fall outside Salesforce’s BAA and need their own agreements and reviews.

What HIPAA Requires from a CRM Platform

HIPAA applies to covered entities, such as health plans, healthcare clearinghouses, and most healthcare providers, and to the business associates that handle protected health information on their behalf. Protected health information, or PHI, is individually identifiable health information, including names, contact details, and record numbers when they’re linked to health conditions, care, or payment. A CRM that stores patient intake details, care plans, referral notes, or member service cases almost always holds PHI.

It helps to list what counts as protected health information in a typical CRM before any design work starts. Patient names linked to appointment types, referral reasons, insurance member IDs, care plan goals, and case notes about symptoms all qualify. So do call recordings and chat transcripts in which patients describe their condition. Even an email address becomes PHI when it’s stored on a record that shows the person is a patient of a specific clinic. A HIPAA-compliant Salesforce design starts from that inventory, because every object and field on the list needs access rules, encryption decisions, a retention period, and an owner.

Three HIPAA rules matter most for a CRM. The Privacy Rule controls how PHI can be used and disclosed. The Security Rule sets administrative, physical, and technical safeguards for electronic PHI. The Breach Notification Rule sets the steps an organization must take when unsecured PHI is exposed. For a cloud CRM, the Security Rule drives most of the design work, because it covers access control, audit controls, integrity, authentication, and transmission security.

The Security Rule is risk-based. It expects each organization to run a risk analysis, decide which safeguards are reasonable for its environment, and document those decisions. NIST’s SP 800-66 Revision 2 guide to implementing the HIPAA Security Rule walks through each safeguard in detail, and it’s a practical reference for teams mapping Salesforce settings to HIPAA requirements. Your Salesforce design should follow from that risk analysis.

Is Salesforce HIPAA Compliant?

The accurate answer is that Salesforce can support HIPAA compliance, while compliance itself belongs to the organization using it. HHS guidance on HIPAA and cloud computing explains that a cloud service provider that creates, receives, maintains, or transmits electronic PHI for a covered entity is a business associate. The covered entity must have a BAA in place before it puts PHI in the service. HHS also makes clear that the customer still has to run its own risk analysis and manage its own safeguards.

Salesforce offers that agreement. Its compliance site’s HIPAA section tells customers who want to build HIPAA-compliant applications to contact their account representative about a Business Associate Addendum. The BAA isn’t self-service or automatic, and it isn’t included just because a company buys a healthcare product. It has to be requested, negotiated, and signed, and it has to name the services where PHI will live.

That’s why the phrase “HIPAA-compliant Salesforce” is shorthand. It describes an org where 3 things are true at once: a signed BAA covers the services in use, the org follows the BAA’s restrictions, and the organization has implemented the safeguards HIPAA requires. Remove any one of those, and the org isn’t compliant, whatever edition or cloud it runs. For the safeguards layer, the ONC and OCR Security Risk Assessment Tool offers a free starting point for smaller organizations that need to document their risk analysis.

Which Salesforce Services the Business Associate Agreement Covers

Salesforce publishes a list of HIPAA Covered Services, and the list is much broader than many people assume. Salesforce’s page on Business Associate Addendum restrictions was last updated on July 31, 2026, and it states that 2 conditions must be met for a service to be covered: the customer and Salesforce must sign a BAA that includes that service, and the customer must follow the BAA and the restrictions on that page.

The table below summarizes common services on the list and the conditions attached to some of them.

The key point for this topic is that Salesforce Health Cloud isn’t the only path to a HIPAA-compliant Salesforce org. A healthcare contact center can run on Service Cloud, and a provider relations team can use Sales Cloud, as long as the BAA names those services and the org is configured correctly. Health Cloud’s value lies in its healthcare functionality, which the next sections cover.

Read the list for what’s missing as well. Services that don’t appear on it shouldn’t hold protected health information, even if they connect easily to a covered org. Marketing Cloud Account Engagement, formerly Pardot, doesn’t appear on the list as of the July 2026 update, so teams using it for healthcare marketing should keep PHI out of it or confirm coverage with Salesforce in writing.

What the Business Associate Agreement Excludes or Restricts

The same Salesforce page lists service-specific restrictions, and several of them affect everyday healthcare builds. Reading this section before designing a HIPAA-compliant Salesforce org prevents costly rework later.

Some features sit inside covered services but are excluded. The Discover feature included with Lightning Platform isn’t covered, so customers can’t enable it in a way that sends PHI to it. The Marketing Cloud Einstein features in Marketing Cloud Growth and Advanced aren’t covered either. Commerce Cloud Einstein is excluded from the B2C Commerce coverage, and Tableau Bridge, Tableau Data Connect, and Tableau Server are excluded from Tableau coverage.

Other services carry usage rules. Einstein Bots can’t receive PHI in utterance records, and customers can’t enable Answer Automation or Input Recommender features in a way that puts PHI into them. Heroku coverage applies only inside Shield Private Spaces and related Shield services, so standard Private Spaces and the Common Runtime can’t hold PHI. Slack coverage requires an Enterprise plan with the HIPAA-enabled SKU, and patients, plan members, and their families can’t be added as users.

The encryption clause applies across all covered services. Salesforce states that the customer is responsible for secure transmission of PHI and must encrypt PHI transmitted using the covered services and, to the extent within the customer’s control, stored in them. That encryption has to meet HHS guidance on rendering PHI unusable, unreadable, or indecipherable. Covered services also exclude any portion deployed on the customer’s own premises.

Finally, the BAA covers Salesforce’s own services only. AppExchange apps built by independent vendors, custom integrations, and external systems connected to your org aren’t part of Salesforce’s agreement. Each vendor that touches PHI needs its own BAA and its own security review.

What Salesforce Health Cloud Actually Adds

Salesforce Health Cloud adds healthcare-specific data models, workflows, and user experiences to the Salesforce platform. It’s designed for providers, payers, and related healthcare organizations that need to manage patients or members, care teams, and care programs in one place. Its value is functional. It gives teams a structure for healthcare work that they’d otherwise have to build from scratch on Sales Cloud or Service Cloud.

Common Health Cloud capabilities include a patient or member view that brings together demographics, conditions, care team members, and interactions. Care plans and care programs help coordinate tasks and goals across clinicians and coordinators. Intake and referral management support the path from first contact to scheduled care, and payer-focused features support work such as utilization management and provider network management. The Salesforce Health Cloud clinical data model gives teams standard objects for clinical information, which makes EHR integration more consistent.

These features can change operations in measurable ways when they’re configured around real workflows. In a VALiNTRY360 Health Cloud project for AthenaPsych, a New York State mental health provider, VALiNTRY360 reports that 80% of patients were scheduled on the first call in the first 6 months after Phase 1. The same case study reports a 69% drop in CPT coding errors and a 75% drop in clinical compliance errors.

Notice what those gains come from. They come from workflow design and better data, and none of them come from a HIPAA setting inside Health Cloud. Health Cloud gives you healthcare structure, while HIPAA compliance comes from the agreement and safeguards around it. Organizations that plan Salesforce for healthcare projects well treat those as 2 separate workstreams that meet at the design stage.

What Health Cloud Doesn’t Cover: The Shared Responsibility Model

Salesforce Health Cloud doesn’t sign your BAA or configure your access model. It doesn’t decide who can see a behavioral health note, train your staff, or vet the AppExchange apps your team installs. Those responsibilities sit with the healthcare organization under a shared responsibility model, which is the same model that applies to most cloud services.

The table shows why buying Health Cloud isn’t a plan for a HIPAA-compliant Salesforce org. Most of the controls an auditor will ask about are configuration choices and operating processes. An org can run Health Cloud under a signed BAA and still fail a HIPAA review because care coordinators can see every patient or a document-generation app sends PHI to an uncovered service.

The healthcare organization also owns data quality and data flow decisions. It decides which PHI enters Salesforce at all, which systems remain the source of truth, and how long records are kept. Teams that bring in Salesforce consulting for health and life sciences often start with a data map for exactly this reason, because every later control depends on knowing where PHI lives.

Where Salesforce Shield Fits

Salesforce Shield is a set of security add-ons that most teams building a HIPAA-compliant Salesforce org rely on to meet their side of the shared responsibility model. It’s on the HIPAA Covered Services list, but it’s sold separately from Health Cloud, Sales Cloud, and Service Cloud. Budget for it early, because retrofitting encryption after data is loaded is harder than enabling it before go-live.

Shield Platform Encryption encrypts sensitive fields, files, and attachments at rest while keeping most platform features working. It supports customer-controlled key material, which helps organizations meet the BAA’s requirement to encrypt stored PHI where it’s within their control. Deterministic encryption lets users filter on some encrypted fields, but it involves trade-offs, so apply it only where filtering is essential.

Event Monitoring records user activity such as logins, report exports, API calls, and record views. That supports the Security Rule’s audit control standard and helps detect behavior such as a user exporting a large patient list. Field Audit Trail extends field history retention well beyond the standard limits, which helps when auditors or investigators need to see how a record changed over time. Plan log retention deliberately, because monitoring data that isn’t stored can’t support a later investigation.

Key management deserves its own plan. Decide who can rotate or destroy keys, how key material is backed up, and what happens to encrypted data if a key is revoked. Losing a key can make data unreadable for your own staff, so test rotation in a sandbox first and write the procedure into your security policies.

Encryption also affects breach exposure. HHS guidance treats PHI that has been rendered unusable, unreadable, or indecipherable through approved encryption as secured, and a breach of secured PHI doesn’t trigger the same notification duties as unsecured PHI. Strong encryption with sound key management is one of the most practical ways to limit the impact of an incident.

Access Controls and Minimum Necessary in Health Cloud

HIPAA’s minimum necessary standard asks organizations to limit PHI use and disclosure to what a task actually requires. In a HIPAA-compliant Salesforce org, that translates into a deliberate access model built from profiles, permission sets, sharing rules, and field-level security. Health Cloud adds care team structures that can drive record access, but the organization still has to design the rules.

Start with a private sharing model for patient and member records, then open access by role and relationship. A care coordinator may need full access to the patients on their care team and no access to anyone else. A billing specialist may need payment details but not clinical notes. Field-level security can hide sensitive fields, such as behavioral health or substance use information, from users who don’t need them. Review those rules whenever roles change, because access tends to grow over time.

Authentication matters just as much. Require multifactor authentication or single sign-on with strong authentication for every user who can reach PHI, and remove shared accounts. Set session timeouts and login IP ranges that match how your staff actually work. Recent Salesforce platform security changes also affect these settings, so review them after each release.

Patient-facing portals need their own design. Experience Cloud is on the covered list, but a portal exposes PHI to external users, so sharing mistakes become visible to patients. Build patient access around each user’s own records, lock down guest pages, and test with real patient test accounts. A dedicated Salesforce healthcare portal build usually includes this access testing before launch.

AI, Agentforce, and Protected Health Information

AI features are where HIPAA-compliant Salesforce design has changed the most. Salesforce lists many Einstein and Agentforce services as covered, including Agentforce Service Agent, Prompt Builder, and several Einstein GPT services. The restrictions that come with them are specific, and healthcare teams need to design around them from the start.

Salesforce states that Einstein services can’t be used as a substitute for professional medical advice, as a medical device or software function for diagnosis or treatment, or to infer or predict an individual’s medical condition, status, program eligibility, or outcome. That means an agent can help a patient reschedule an appointment or check a claim status, but it can’t be used to decide whether a patient qualifies for a care program based on their health data.

The BAA page also requires customers to enable, maintain, and use Data Masking in the Einstein Trust Layer for Agentforce services and Prompt Builder, to the extent within the customer’s control. For Einstein GPT services that use a third-party large language model, the customer is responsible for making sure that model provider meets HIPAA requirements. Document these settings in your AI governance records, because they’re conditions of coverage and they can change with each update to the BAA page.

Start with narrow, low-risk use cases. Appointment scheduling, benefits questions, and case summaries for internal staff are common first steps. Healthcare teams exploring Agentforce for healthcare should test each agent’s responses with realistic data, confirm that masking works as expected, and keep a human reviewer in the loop for anything that affects care or coverage decisions.

Marketing, Integrations, and Third-Party Apps

Marketing is a common weak point in a HIPAA-compliant Salesforce program. HIPAA restricts using protected health information for marketing without the patient’s authorization, and marketing tools often receive data automatically from the CRM. Before any campaign uses patient or member data, confirm that the use is permitted, that the marketing tool is a covered service under your BAA, and that only the minimum necessary data flows to it.

Tool choice matters here. Marketing Cloud Engagement is on the covered list, while Marketing Cloud Growth and Advanced are covered with their Einstein features excluded. Account Engagement doesn’t appear on the list. VALiNTRY360’s article on Pardot for healthcare marketing discusses patient engagement campaigns, and teams using that tool should keep PHI out of it unless Salesforce confirms coverage in writing.

Integrations deserve the same scrutiny. An EHR integration, a lab results feed, or a claims connector moves PHI in and out of Salesforce, and every system in that path is part of your HIPAA scope. MuleSoft is covered only on specific infrastructure, and Salesforce requires customers to use its cryptography and data minimization features when PHI is involved. Custom middleware and iPaaS tools from other vendors need their own BAAs.

AppExchange apps are the easiest gap to miss. Document generation, e-signature, telephony, and scheduling apps often process PHI outside Salesforce’s infrastructure. Salesforce’s BAA doesn’t extend to those vendors, so each one needs a separate agreement and a clear record of what data it receives.

Breach Readiness and the Proposed Security Rule Update

Even a well-designed HIPAA-compliant Salesforce org needs a breach plan. The HHS Breach Notification Rule requires covered entities to notify affected individuals without unreasonable delay and no later than 60 days after discovering a breach of unsecured PHI. Breaches affecting 500 or more residents of a state or jurisdiction also require notice to prominent media outlets, and HHS must be notified on a timeline that depends on the size of the breach.

Salesforce’s role in an incident is set by the BAA, which requires it to report certain incidents to the customer. The healthcare organization then assesses whether a breach occurred, decides who must be notified, and documents the process. Event Monitoring data, Field Audit Trail history, and clear records of who had access to what are the evidence that makes that assessment possible. Test your incident response plan against a realistic Salesforce scenario, such as a compromised user account that exported a patient report.

The rules may tighten. HHS published a proposed HIPAA Security Rule update in the Federal Register on January 6, 2025. It would make encryption of electronic PHI and multifactor authentication required with limited exceptions, and it would add requirements such as regular vulnerability scanning and stronger business associate oversight. As of September 2026, HHS hadn’t issued a final rule, and the timing and final content remain uncertain. Building encryption, MFA, and asset inventories into your Salesforce program now reduces the work if the rule is finalized.

A HIPAA Readiness Checklist for Salesforce

The checklist below brings the earlier sections together into an order most healthcare teams can follow. It works for new HIPAA-compliant Salesforce implementations and for reviews of existing orgs.

1.      Run a risk analysis. Identify where PHI enters, lives in, and leaves Salesforce, and document the safeguards you choose.

2.      Sign the BAA. Request the business associate agreement from your account team and confirm it names every service that will hold PHI.

3.      Check the restrictions page. Compare your planned features against Salesforce’s current BAA restrictions, including AI, marketing, and analytics exclusions.

4.      Enable encryption. Use Shield Platform Encryption for PHI at rest, and confirm that every integration uses encrypted transport.

5.      Design least-privilege access. Use a private sharing model, care team-based access, field-level security, and MFA for every user.

6.      Turn on monitoring. Enable Event Monitoring and Field Audit Trail, set retention periods, and assign someone to review alerts.

7.      Review apps and integrations. List every AppExchange app and integration that touches PHI, and confirm each has its own BAA.

8.      Govern AI features. Enable Data Masking in the Einstein Trust Layer and document which use cases are allowed.

9.      Train your users. Cover PHI handling in Salesforce, including reports, exports, and sharing.

10.   Test and reassess. Review access, BAA coverage, and restrictions at least annually and after major Salesforce releases.

Existing orgs often drift from their original design. New fields, new apps, and new users add up over time, and a control that worked at launch may no longer match the org. A Salesforce health check that includes a HIPAA-focused review of sharing, encryption, and connected apps is a practical way to find those gaps before an auditor does.

Conclusion

A HIPAA-compliant Salesforce org rests on 3 layers: a business associate agreement that names every service holding PHI, a configuration that follows Salesforce’s restrictions, and the administrative and technical safeguards HIPAA expects from every covered entity. Salesforce Health Cloud strengthens that foundation with healthcare data models and care coordination workflows. It doesn’t replace the agreement or the safeguards.

The practical gaps sit in predictable places. Encryption at rest usually needs Salesforce Shield, AI features need Data Masking and clear use limits, marketing tools need coverage checks, and AppExchange apps need their own agreements. Organizations that map their PHI, read the BAA restrictions page before design work, and review their org regularly can use Salesforce confidently for patient and member engagement. Those that assume Health Cloud handles compliance on its own tend to discover the gaps during an audit or an incident.

Frequently Asked Questions

Is Salesforce HIPAA compliant?

Salesforce can support HIPAA compliance, but no software is compliant on its own. You need a signed business associate agreement covering the services you use, a configuration that follows Salesforce’s restrictions, and your own HIPAA safeguards and policies.

Does Salesforce sign a business associate agreement?

Yes. Salesforce offers a Business Associate Addendum for its HIPAA Covered Services. Customers request it through their account team, and it must name the services where PHI will be stored or processed.

Is Health Cloud the only HIPAA-covered Salesforce product?

No. Salesforce’s covered services list includes Sales Cloud, Service Cloud, Experience Cloud, Salesforce Shield, Data 360, Marketing Cloud Engagement, and many other services alongside Health Cloud.

What does Salesforce Health Cloud add for healthcare organizations?

Health Cloud adds healthcare data models and workflows, such as patient and member views, care plans, care teams, intake and referral management, and payer features like utilization management. It adds functionality, while compliance comes from the BAA and your safeguards.

Do I need Salesforce Shield for HIPAA compliance?

Shield isn’t named as mandatory, but Salesforce’s BAA requires customers to encrypt stored PHI where it’s within their control. Most healthcare orgs use Shield Platform Encryption for that, along with Event Monitoring and Field Audit Trail for audit controls.

Which Salesforce features are excluded from the BAA?

Examples include the Lightning Platform Discover feature, Marketing Cloud Einstein features in Growth and Advanced, Commerce Cloud Einstein, and Tableau Bridge, Data Connect, and Server. Check Salesforce’s restrictions page for the current list.

Can I use Agentforce with protected health information?

Several Agentforce and Einstein services are covered, but Salesforce bars using them for diagnosis, treatment, or predicting a person’s health condition or eligibility. Customers must also enable Data Masking in the Einstein Trust Layer where it’s within their control.

Are AppExchange apps covered by Salesforce’s BAA?

No. AppExchange apps from independent vendors fall outside Salesforce’s agreement. Each vendor that processes PHI needs its own BAA and security review.

Can I use Marketing Cloud with patient data?

Marketing Cloud Engagement is a covered service, and Marketing Cloud Growth and Advanced are covered with their Einstein features excluded. HIPAA also restricts using PHI for marketing without patient authorization, so check both coverage and permission before any campaign.

Is Marketing Cloud Account Engagement (Pardot) HIPAA covered?

Account Engagement doesn’t appear on Salesforce’s HIPAA Covered Services list as of the July 2026 update. Keep PHI out of it unless Salesforce confirms coverage in writing.

Who is responsible for encryption in a HIPAA-compliant Salesforce org?

Salesforce provides encryption tools, but its BAA makes the customer responsible for encrypting PHI in transit and, where within the customer’s control, at rest, consistent with HHS guidance.

What happens if PHI in Salesforce is breached?

The healthcare organization must assess the incident and, for a breach of unsecured PHI, notify affected individuals within 60 days of discovery. Larger breaches also require notice to HHS and, in some cases, the media.

Is the new HIPAA Security Rule in effect?

No. HHS proposed an update in January 2025 that would require encryption and multifactor authentication with limited exceptions, but no final rule had been issued as of September 2026.

Can patients use a Salesforce portal with their health information?

Yes. Experience Cloud is a covered service, so patient portals can display PHI under a signed BAA. The portal needs strict sharing rules, secure guest pages, and testing with patient test accounts before launch.

How often should we review our Salesforce HIPAA setup?

Review access, BAA coverage, and restrictions at least once a year, after major Salesforce releases, and whenever you add new apps, integrations, or AI features.