Salesforce HIPAA Compliance: BAA, Requirements, and a Step-by-Step Setup Guide

Business Associate Agreement Overview

A Business Associate Agreement (BAA) is the legal foundation that allows you to handle Protected Health Information (PHI) in Salesforce. It defines permitted uses, safeguards, breach notification duties, and the specific “Covered Services” where PHI may reside.

You must execute a BAA with Salesforce before storing or processing any PHI in your org. The BAA complements your internal Security Configuration, ensuring technical, administrative, and physical controls align with HIPAA’s Security Rule.

Key elements you should confirm

• Scope: Which Salesforce services and editions are “covered” for PHI under your BAA.
• Safeguards: Required Encryption Standards, access controls, and Audit Logs you must maintain.
• Incident duties: Time-bound breach notification and cooperative investigation processes.
• Subcontractors: How downstream service providers are managed and supported by Compliance Training and contracts.
• Data lifecycle: Procedures for return, deletion, and retention of PHI on termination.

Practical implications

Map PHI data flows and restrict PHI strictly to covered features and environments. Document responsibilities, train your workforce, and establish governance to review new features, integrations, and releases before enabling them for PHI.

Covered Salesforce Services

Only services explicitly listed as covered in your executed BAA should store or process PHI. Treat the BAA and accompanying documentation as the source of truth; coverage can vary by contract, edition, and feature set.

Common patterns seen in healthcare deployments

• Core platform capabilities configured for HIPAA with Role-Based Access Control and encryption.
• Health Cloud features used for care management when included in the covered scope.
• Security add-ons (for example, platform encryption, event monitoring, field history tools) to meet Encryption Standards and Audit Logs requirements.
• Experience/portal use restricted to covered components with strict access, sharing, and content controls.

Typical exclusions to handle carefully

• Beta, pilot, “Labs,” or experimental features not listed as covered.
• Third‑party add‑ons or integrations without their own BAAs.
• Unvetted email, SMS, or file-sharing workflows that could transmit PHI outside covered services.
• Sandboxes and training orgs holding production PHI without approved masking or de‑identification.

Configuring Security Settings

Step-by-Step Setup Guide

1. Establish governance and data classification.

Identify PHI fields, label sensitive objects, and define who may access them. Create a change control process to review any new PHI use case before deployment.

Harden identity and sessions.

Enforce SSO with MFA, set strict session timeouts, restrict login IP ranges, and require modern authentication methods for all users accessing PHI.

Implement Role-Based Access Control.

Use least privilege with profiles, permission sets, and OWD sharing. Limit “View All/Modify All,” apply field-level security to PHI, and segregate admin duties from clinical users.

Apply Encryption Standards.

Enable platform encryption for PHI fields and files, manage keys securely, rotate keys on a defined schedule, and enforce TLS for data in transit across integrations.

Constrain data exposure.

Block inline PHI in subject lines, chatter posts, and URLs. Use page layouts, dynamic forms, and validation rules to limit accidental disclosure.

Enable Audit Logs and monitoring.

Activate event and field-level auditing for access, exports, API calls, and admin changes. Stream logs to your SIEM and define alert thresholds for anomalous behavior.

Secure integrations and APIs.

Use named credentials, minimal OAuth scopes, and IP allowlists. Avoid query-string PHI, sign and encrypt payloads, and restrict callbacks to covered endpoints.

Prevent data loss.

Control report and file exports, disable risky sharing, and review third‑party connectors. Add transaction security policies to block or flag high‑risk actions.

Backups and recovery.

Schedule backups, test restores, and store copies with providers under a BAA. Define RPO/RTO objectives and document restoration procedures.

Sandbox and non‑prod discipline.

Use masking or synthetic data in sandboxes. Restrict non‑prod access, remove PHI where not required, and audit refresh pipelines regularly.

Operational runbooks.

Create incident response, change management, and access review playbooks. Assign owners, SLAs, and escalation paths for each procedure.

Compliance Training and attestations.

Train all users on HIPAA, acceptable use, and data handling. Track completions and require re‑certification after role changes or policy updates.

Utilizing Salesforce Health Cloud

Health Cloud centralizes patient profiles, care plans, and care team collaboration while giving you granular control over PHI. Configure it to reflect your clinical model and apply the same Security Configuration rigor you use across the platform.

Model clinical data intentionally

Define person records, encounters, assessments, and care plans based on real workflows. Use field-level security and encryption for diagnoses, medications, and notes holding PHI.

Consent and communication preferences

Capture consent types (treatment, payment, operations, research) and channel preferences. Enforce consent at automation points so messages containing PHI are only sent when authorized.

Care teams and collaboration

Use care team roles to scope visibility, not broad public groups. Guide users to collaborate without placing free‑text PHI in unrestricted chatter or emails, and apply content scanning where available.

Integration considerations

For EHR, FHIR, or claim feeds, secure endpoints, sign payloads, and validate that every intermediary vendor maintains a BAA. Log interface traffic and reconcile exceptions promptly.

Implementing Shared Responsibility Model

HIPAA compliance on Salesforce is shared. Salesforce secures the underlying cloud platform, while you configure controls, govern data, train staff, and manage downstream risk to keep PHI protected.

Salesforce responsibilities

• Protect the infrastructure, core platform, and foundational encryption and availability controls.
• Vet and manage sub‑processors and provide transparency into platform security and incidents.

Your responsibilities

• Design and maintain Role-Based Access Control, encryption of PHI, monitoring, and incident response.
• Validate integrations, manage vendors under BAAs, and enforce Security Configuration policies.
• Provide workforce Compliance Training and continuous access re‑certification.

Joint responsibilities

• Coordinate breach response, evidence collection, and required notifications under the BAA.
• Review releases and new features before enabling them for PHI use cases.

Conducting Ongoing Compliance Audits

Auditing proves your controls work over time. Build a cadence that aligns to HIPAA’s administrative, physical, and technical safeguards, and keep evidence organized for assessments.

Administrative safeguards

• Annual risk analysis, policy reviews, and workforce training verification.
• Quarterly user access re‑certification and separation‑of‑duties checks.

Technical safeguards

• Monthly reviews of Audit Logs for exports, API spikes, and admin changes.
• Encryption key rotation checks, vulnerability remediation, and sandbox masking attestations.

Operational drills and evidence

• Tabletop breach simulations and restore tests with documented outcomes.
• Dashboards tracking exceptions, SLAs, and corrective actions to closure.

Accessing Compliance Resources and Support

Rely on official product security guides, release notes, and platform status resources to plan secure deployments. Engage your account team and solution architects to validate designs against your BAA.

Partner and internal enablement

• Use vetted implementation partners experienced in HIPAA to accelerate secure designs.
• Create an internal knowledge base with runbooks, standards, and decision records.
• Schedule refresher briefings after major releases to reassess risk and configuration.

Conclusion

Salesforce can support HIPAA when you pair a signed BAA with rigorous Security Configuration, encryption, Role-Based Access Control, and continuous monitoring. Treat covered services as the legal boundary for PHI, audit relentlessly, and keep people trained to maintain strong, verifiable compliance.

FAQs.

What is a Business Associate Agreement in Salesforce?

A Business Associate Agreement is the contract that permits PHI use on Salesforce, defines which services are covered, and allocates safeguards, breach notifications, and data lifecycle obligations between you and Salesforce.

Which Salesforce services are covered under HIPAA compliance?

Only the services explicitly listed in your executed BAA are covered. Use those as the boundary for PHI and treat all other features, pilots, and third‑party add‑ons as non‑covered unless separately documented.

How does Salesforce support encryption for HIPAA?

Salesforce supports strong Encryption Standards through platform capabilities that encrypt PHI fields and files at rest and enforce modern TLS in transit. You manage key lifecycle, rotation, and which fields and objects are encrypted.

What are the responsibilities of healthcare organizations under the shared responsibility model?

You must configure access controls, encryption, and monitoring; train your workforce; govern integrations and vendors via BAAs; and run ongoing audits. Salesforce secures the platform, while you secure how PHI is used within it.