Is Salesforce HIPAA Compliant?

The compliance team at a regional health system just finished a twelve-month implementation of Salesforce Health Cloud. The BAA is signed. The security review is complete. Patient records are flowing through a HIPAA-eligible environment, and the leadership team is celebrating what feels like a major milestone.

Then the marketing team asks a simple question: "Can we connect Marketing Cloud to run our patient outreach campaigns?"

That question exposes the central challenge with Salesforce and HIPAA. Health Cloud is genuinely built for healthcare. Salesforce has invested heavily in healthcare-specific features, earned certifications, and built a platform that can handle protected health information when configured correctly. But Salesforce is not one product. It is an ecosystem of dozens of products, thousands of AppExchange integrations, and multiple independent cloud platforms. The BAA that covers Health Cloud does not automatically extend to every product in that ecosystem.

For healthcare organizations, the distinction matters enormously. The compliance boundary is not "Salesforce." It is a specific list of Salesforce products, configured in a specific way, with specific features enabled.

The Product-by-Product Compliance Puzzle

Salesforce publishes a list of products eligible for its BAA, and the inclusions and exclusions reveal how fragmented the compliance picture truly is.

Products covered under Salesforce's BAA (when properly configured):

• Salesforce Health Cloud

• Salesforce Shield (encryption, event monitoring, field audit trail)

• Salesforce Platform (core CRM, when Health Cloud is active)

Products NOT covered under Salesforce's BAA:

• Marketing Cloud

• Pardot (now called Marketing Cloud Account Engagement)

• Commerce Cloud

• Tableau (in most configurations)

• Many AppExchange third-party integrations

• Salesforce Communities (in standard configurations)

• Web-to-Lead and Web-to-Case forms (client-side)

This fragmentation creates a specific and dangerous pattern. A health system signs a BAA for Health Cloud, builds its patient management workflows there, and then begins connecting other Salesforce products. Data flows from Health Cloud into Marketing Cloud for campaign segmentation. Lead capture forms on the website use Salesforce's Web-to-Lead feature. Pardot tracks email engagement. Each connection moves data outside the BAA boundary, often without anyone recognizing the shift.

Where Health Data Escapes the BAA Boundary

Understanding exactly how data crosses from covered to uncovered territory is critical for any healthcare organization running Salesforce.

Web-to-Lead and Web-to-Case forms. These features embed client-side forms on your website. When a patient fills out a form to request an appointment or ask a question, that data travels through the visitor's browser before reaching Salesforce. The form submission itself is a client-side operation. If the form collects any health-related information (appointment type, condition, insurance details), that data is transmitted outside the BAA-covered environment.

Marketing Cloud integrations. When a healthcare organization connects Health Cloud to Marketing Cloud for patient outreach, contact records, engagement history, and segmentation data flow into a product that does not have BAA coverage. A campaign targeting "patients who visited the cardiology department in the last 90 days" moves health information into a non-covered environment, even if the source data was stored compliantly in Health Cloud.

Pardot tracking and email analytics. Pardot places tracking cookies and monitors email engagement using client-side pixels. When a patient opens a marketing email or clicks a link, Pardot captures that interaction through browser-based tracking. For healthcare organizations, this means patient engagement with health-related content is being tracked by a product without BAA coverage. For a deeper look at Pardot specifically, see our analysis of whether Pardot is HIPAA compliant.

AppExchange integrations. The Salesforce AppExchange hosts thousands of third-party applications. Each integration introduces its own compliance profile. A scheduling widget, a chat tool, or an analytics dashboard installed from AppExchange operates under its own vendor's terms, not Salesforce's BAA. Healthcare organizations frequently install these tools without evaluating whether each one can independently support a BAA.

$193 Million in Settlements Started with Ordinary Marketing Tools

The pattern of health data leaking through marketing and analytics tools is not theoretical. Since 2023, healthcare organizations have paid over $193 million in settlements and enforcement actions tied to tracking technology on their websites and portals. Every major case involved standard marketing tools doing exactly what they were designed to do.

Advocate Aurora Health settled for $12.25 million after installing Meta Pixel and Google Analytics on its website, app, and patient portal. The stated goal was to "better understand patient needs." The result was approximately 3 million patients' data shared with Meta and Google without consent. The tools were working as configured. The problem was that the configuration sent health-related data to platforms without BAAs.

NewYork-Presbyterian Hospital paid $300,000 to the New York Attorney General after using third-party tracking pixels on its website for marketing from 2016 to 2022. The enforcement action specifically cited that NYP had no internal policies or procedures for vetting tracking tools before deployment. Over 54,000 individuals were affected.

BetterHelp's $7.8 million FTC settlement revealed another governance failure: a recent college graduate with no marketing training was placed in charge of deciding what user data was uploaded to Facebook. Health intake questionnaire responses were shared with Facebook, Snapchat, Criteo, and Pinterest via tracking pixels.

These cases share a common thread with the Salesforce compliance challenge. Organizations assumed that because their core system was compliant (or because a BAA existed somewhere in the stack), the connected marketing tools were covered too. They were not.

What "Configured Correctly" Actually Requires

Even within Health Cloud's BAA-covered environment, Salesforce compliance is not automatic. The BAA is contingent on specific configurations that the customer must implement and maintain.

Salesforce Shield is effectively mandatory. Shield provides platform encryption, event monitoring, and field audit trail. Without Shield, data at rest in Salesforce is not encrypted with customer-controlled keys, and audit logging lacks the granularity HIPAA requires. Shield is a paid add-on, not included in standard Health Cloud licensing.

Field-level encryption must be configured manually. Salesforce does not encrypt all fields by default. Healthcare organizations must identify which fields contain PHI and enable encryption for each one. A misconfigured field means unencrypted health data.

Sharing rules and role hierarchies need healthcare-specific design. Salesforce's default sharing model is built for sales teams, not clinical workflows. Without careful configuration, a marketing user might have read access to patient health records simply because of how the org's sharing rules are structured.

Session settings, login IP ranges, and MFA enforcement all need to be configured to meet the HIPAA Security Rule's access control requirements. These are customer responsibilities, not defaults.

The gap between "we signed a BAA" and "our Salesforce org is actually compliant" can be enormous. The BAA provides the legal framework. The configuration provides the actual protection.

The Website Blind Spot: Why Your CRM BAA Does Not Cover Your Web Properties

Here is where the Salesforce compliance conversation intersects with a broader problem that affects every healthcare organization. Your CRM might be locked down perfectly. Health Cloud might be configured with Shield encryption, proper sharing rules, and a signed BAA. But your website is a separate attack surface entirely.

Healthcare marketing teams routinely add scripts, tracking pixels, chat widgets, and analytics tools to the organization's website. These tools operate client-side, in the patient's browser, completely outside the Salesforce environment. A Salesforce BAA has no bearing on whether your website's Google Analytics implementation, your Meta Pixel, or your third-party appointment scheduler is transmitting health information to vendors without BAAs.

This is where ongoing compliance monitoring becomes essential. A web scanner that continuously crawls your site can detect every cookie, script, localStorage entry, and tracking pixel across every page. It flags which scripts lack a BAA, which cookies are set by third parties, and which tracking pixels are sending data to ad platforms. Without continuous scanning, you are relying on the hope that nobody on your marketing team (or any third-party plugin) introduced a non-compliant script since your last manual audit.

Every enforcement case in the reference data involved tracking that had been running for months or years before anyone noticed. Advocate Aurora's pixels ran for five years. NYP's ran for six. The tools were visible in the browser's developer console the entire time. Nobody checked.

Building a Compliant Healthcare Marketing Stack Around Salesforce

For organizations committed to Salesforce Health Cloud as their CRM, the question becomes: how do you handle the marketing, analytics, and web tracking functions that fall outside Health Cloud's BAA coverage?

Server-side architecture for data collection. Client-side tracking (pixels, JavaScript tags) sends data through the visitor's browser to third parties. Server-side tracking sends data from your server to destinations. The browser never talks to Facebook, Google, or any third party directly. This is not a technical preference. It is the architectural difference between data that can leak and data that cannot. A server-side CDP can collect patient interactions, apply consent rules, and route data to Salesforce Health Cloud without exposing health information in the browser.

Consent-gated data flows. Data should only move to any destination (including Salesforce) after consent is verified server-side. A JavaScript-based consent check can be bypassed, disabled, or loaded out of order. Server-side consent enforcement means the data never leaves your infrastructure until consent is confirmed.

SOC 2 Type II with all five trust criteria. When evaluating any tool that will handle health data alongside Salesforce, look for SOC 2 Type II covering Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most vendors certify only Security (one of five). All five criteria mean independent auditors verified that the vendor handles data with the rigor healthcare demands. Type II (not Type I) means sustained compliance over a review period, not a point-in-time snapshot.

Independent BAAs for every tool in the chain. The Salesforce Health Cloud BAA covers Salesforce Health Cloud. Your analytics tool needs its own BAA. Your tag manager needs its own BAA. Your session replay tool needs its own BAA. The compliance chain is only as strong as its weakest link.

An Evaluation Framework for Salesforce in Healthcare

Before concluding that your Salesforce deployment is compliant, walk through these questions:

1. Which Salesforce products are you actually using? List every Cloud, every AppExchange app, every integration. Check each one against Salesforce's BAA-eligible product list.

2. Where does data flow between covered and uncovered products? Map every integration point. If Health Cloud data reaches Marketing Cloud, Pardot, or any non-covered product, that flow needs to be addressed.

3. Is Salesforce Shield active and configured? Encryption, event monitoring, and audit trails are not optional for HIPAA. Verify that Shield is licensed and that PHI fields are encrypted.

4. What client-side Salesforce features are deployed on your website? Web-to-Lead forms, chat widgets, and embedded Salesforce components operate in the browser. Evaluate whether they handle health information.

5. What non-Salesforce tools are running on your website? Your CRM compliance is irrelevant if your website is leaking data through tracking pixels. Run a comprehensive scan of every script, cookie, and tracker on your site.

6. How will you detect changes over time? Marketing teams add tools. Plugins update. Third-party tags load other tags. Without continuous monitoring, compliance is a point-in-time assertion that degrades the moment someone adds a new script.

The Consent Frontier

The regulatory landscape for healthcare marketing technology is shifting toward consent as a foundational requirement. State privacy laws are multiplying. Patient expectations around data control are rising. The OCR guidance on tracking technologies (issued December 2022, updated and partially challenged since) signaled that regulators view website tracking in healthcare as a serious compliance concern.

For Salesforce users, this means that even Health Cloud's BAA-covered environment will increasingly need to integrate with consent management infrastructure. Consent-gated data dispatch, where data only flows to Salesforce after verified patient consent, is becoming the expected standard rather than a nice-to-have.

Organizations that build consent into their data architecture now will be ahead of both regulatory requirements and patient expectations. Those that treat consent as a checkbox will face the same reckoning that tracking pixel users faced starting in 2023.

Frequently Asked Questions

Does Salesforce offer a BAA for healthcare organizations?

Yes, but only for specific products. Salesforce Health Cloud, Salesforce Shield, and certain platform features are eligible for BAA coverage. Marketing Cloud, Pardot, Commerce Cloud, and most AppExchange integrations are not covered. The BAA applies to the products listed in Salesforce's HIPAA compliance documentation, not to the Salesforce ecosystem as a whole.

Can I use Salesforce Marketing Cloud for patient outreach?

Marketing Cloud is not covered under Salesforce's BAA. If your patient outreach campaigns involve any health-related data (appointment types, conditions, care history, or even the fact that someone is a patient), routing that data through Marketing Cloud creates a compliance gap. Organizations that need marketing automation for healthcare audiences should evaluate whether their data flows keep PHI within BAA-covered boundaries.

Is Salesforce's Web-to-Lead feature safe for healthcare websites?

Web-to-Lead forms operate client-side, meaning data passes through the visitor's browser before reaching Salesforce. If these forms collect any health-related information (appointment requests, condition descriptions, insurance details), that client-side transmission falls outside the protections of a server-side, BAA-covered environment. Server-side form handling is the safer architectural choice for healthcare websites.

What is Salesforce Shield and do I need it for HIPAA compliance?

Salesforce Shield is a paid add-on that provides platform encryption, event monitoring, and field audit trail capabilities. For healthcare organizations handling PHI in Salesforce, Shield is effectively required. Without it, data at rest is not encrypted with customer-managed keys, and audit logging lacks the detail the HIPAA Security Rule expects. Shield is not included in standard Health Cloud licensing and must be purchased separately.

How do I know if my Salesforce org is actually HIPAA compliant right now?

A signed BAA is necessary but not sufficient. You need to verify that Shield is active, PHI fields are encrypted, sharing rules restrict access appropriately, session security settings meet HIPAA requirements, and no data flows connect Health Cloud to non-covered products like Marketing Cloud or Pardot. Beyond Salesforce itself, you need to audit your website for tracking scripts, pixels, and cookies that operate outside your CRM's compliance boundary. Continuous monitoring tools can detect compliance drift that manual audits miss.

Ours Privacy provides a healthcare-grade CDP and web scanner built on server-side architecture with a full BAA, SOC 2 Type II (all five trust criteria), and consent-gated data dispatch. If you are evaluating how to handle analytics, tracking, and marketing data alongside Salesforce Health Cloud, explore how our platform works or review our analysis of related tools like HubSpot, Pardot, and Google Analytics.