SfSkills Domains Docs GitHub

Home / architect / hipaa-compliance-architecture

hipaa-compliance-architecture

Use this skill to design HIPAA-compliant Salesforce org architectures for healthcare organizations storing or processing Protected Health Information (PHI). Trigger keywords: HIPAA BAA, PHI storage, Shield encryption, Health Cloud compliance, HIPAA technical safeguards, covered entity Salesforce architecture. NOT for minimum-necessary access design — use admin/hipaa-workflow-design. NOT for non-healthcare org security review — use architect/security-architecture-review.

Open the skill folder on GitHub

HIPAA Compliance Architecture

This skill activates when designing or reviewing a Salesforce org that must comply with HIPAA for a covered entity or business associate. It provides architecture-level decisions — BAA scope validation, Shield control mapping to HIPAA technical safeguards, PHI storage boundaries, and non-Shield compliance requirements — that go beyond workflow configuration. Use it alongside admin/hipaa-workflow-design for day-to-day operational controls.

Before Starting

Gather this context before working on anything in this domain:

ContextWhat to confirm
BAA statusHas a Business Associate Agreement been signed with Salesforce? Until it is signed, no PHI may be stored in any Salesforce service regardless of encryption or access controls.
Product inventoryCompile every Salesforce product in use — core platform, Health Cloud, Experience Cloud, Shield add-ons, and all AppExchange products. BAA coverage is product-specific; products not listed in the executed BAA are not covered even if they run on covered infrastructure.
Shield licensingConfirm whether the org has Shield Platform Encryption, Field Audit Trail, and/or Event Monitoring enabled. Shield is a paid add-on not included in any Salesforce edition. Verify through Setup > Company Information > Licenses.
PHI categoriesIdentify the 18 HIPAA-defined PHI identifiers the org will handle. This determines which object fields require SPE and which audit retention periods apply.
Third-party integrationsAny connected system that receives PHI must also operate under a BAA or equivalent data processing agreement.

Core Concepts

Business Associate Agreement (BAA) Scope

The BAA is the contractual foundation of HIPAA compliance in Salesforce. Salesforce acts as a Business Associate under HIPAA when it processes PHI on behalf of a Covered Entity or another Business Associate. The executed BAA with Salesforce defines exactly which products and services are covered. Products not explicitly listed in the BAA are outside HIPAA coverage — storing PHI in uncovered services creates a HIPAA breach risk even if the org has Shield enabled.

Key BAA-covered Salesforce products typically include: Health Cloud, Sales Cloud, Service Cloud, Experience Cloud (with restrictions), Shield (SPE, FAT, Event Monitoring), and Tableau CRM (with caveats). Products that are not covered under the standard BAA include standard Chatter (as of current published guidance), certain Einstein features, some AppExchange managed packages (which require their own BAA addenda with the ISV), and Salesforce Sandbox environments unless explicitly addressed.

Practitioners must review the current Salesforce HIPAA BAA help article (help.salesforce.com/s/articleView?id=sf.compliance_hipaa.htm) because covered product lists change with releases.

Salesforce Shield: Three Controls

Shield is a paid add-on bundle providing three distinct compliance controls:

  1. Shield Platform Encryption (SPE) — Encrypts PHI at rest using AES-256 with Salesforce-managed or customer-managed keys (BYOK). Covers field-level and file encryption. Addresses the HIPAA Security Rule technical safeguard for data at rest (45 CFR §164.312(a)(2)(iv) and §164.312(e)(2)(ii)). SPE introduces functional tradeoffs: encrypted fields cannot be used in formula fields, external IDs, unique constraints, sorting, or certain SOQL operations — field selection must be designed carefully.
  2. Field Audit Trail (FAT) — Extends field history tracking retention from 18 months (standard History Tracking limit) to up to 10 years. HIPAA requires covered entities to retain documentation of HIPAA policies and procedures for 6 years from creation or last effective date; medical records retention varies by state but FAT supports the 10-year outer bound. Standard Field History Tracking is insufficient for HIPAA audit requirements.
  3. Event Monitoring — Provides detailed transaction security logs including login history, API calls, report exports, and data access events. Maps to HIPAA Security Rule audit control requirements (45 CFR §164.312(b)). Logs are stored as EventLogFile objects queryable via SOQL or exportable to a SIEM.

Shield addresses a subset of HIPAA technical safeguards. It does not on its own satisfy the full HIPAA Security Rule — see Non-Shield Requirements below.

Non-Shield HIPAA Requirements

Shield is one component of a HIPAA compliance architecture. The HIPAA Security Rule (45 CFR Part 164) requires controls across three categories: Administrative, Physical, and Technical safeguards. Salesforce physical safeguards are covered by Salesforce's infrastructure (documented in their ISMS and SOC 2 reports). The following controls require customer action beyond Shield:

Common Patterns

BAA Scope Boundary Architecture

When to use: Any new Health Cloud or healthcare implementation where PHI will be stored in Salesforce, or when an existing org is expanding feature use (adding AppExchange packages, Experience Cloud portals, Einstein features).

How it works:

  1. Enumerate every Salesforce product and AppExchange package used by the org.
  2. Obtain the current signed BAA and identify the covered product list by name.
  3. For each product not listed, document a BAA coverage gap.
  4. For AppExchange packages: request a signed BAA addendum from each ISV. Until received, treat these services as uncovered and do not write PHI to any field managed by that package.
  5. For Experience Cloud: confirm the specific Experience Cloud template (LWR, Aura, Tabs+VF) is addressed in the BAA; review sharing architecture to ensure PHI-bearing records are not accessible to guest users.
  6. Document the approved product set in the org architecture decision record and enforce via a custom metadata registry (HIPAA_Covered_Service__mdt) checked during deployment validation.

Why not the alternative: Assuming all Salesforce infrastructure is uniformly covered by a single BAA is the most common compliance gap in Salesforce HIPAA implementations. Product-specific coverage is contractual, not technical.

Shield PHI Field Encryption Design

When to use: Designing the SPE encryption policy for a Health Cloud org that has Shield enabled and an executed BAA. Covers field selection, key management approach, and functional limitation mitigation.

How it works:

  1. Conduct a PHI field inventory across all standard and custom objects. Map each field to one of the 18 HIPAA-defined identifiers.
  2. Apply the SPE deterministic encryption scheme to fields that must be searchable (e.g., Name, Phone, Email) — deterministic encryption allows exact-match SOQL queries but does not support range queries or LIKE operators.
  3. Apply probabilistic encryption to fields that require maximum security and do not need to be queried by value (e.g., Social Security Number stored in a custom field, clinical notes text areas).
  4. Do not encrypt fields used in: formula fields, workflow rules that reference field values, external IDs, unique fields, or SOQL ORDER BY clauses — re-architect those query patterns before enabling SPE.
  5. For key management: evaluate whether tenant secret (Salesforce-managed, lowest operational burden) or BYOK (customer-controlled key material, highest control) is required by the organization's security policy. BYOK requires HSM infrastructure.
  6. Document the encryption policy in a data classification matrix and validate in a Sandbox with Shield before production deployment — SPE enablement on existing data triggers an async re-encryption job that can affect org performance.

Why not the alternative: Applying probabilistic encryption to all PHI fields (the "encrypt everything" anti-pattern) breaks SOQL queries, formula fields, and workflow rules silently — flows and automation may produce incorrect results without error messages during testing.

Decision Guidance

SituationRecommended ApproachReason
BAA not yet executed and go-live is imminentBlock PHI entry to the org via validation rules; do not proceed with PHI population until BAA is countersignedNo BAA = no HIPAA coverage regardless of technical controls
AppExchange package will store PHI (e.g., e-signature, document generation)Obtain a signed BAA addendum from the ISV before activationManaged packages are separate business associates; ISV data handling is outside Salesforce's BAA
Team requests standard Chatter for clinical care team collaborationRedirect to Salesforce Communities or a BAA-covered messaging channel; document risk if standard Chatter is used with PHIStandard Chatter is not covered under the Salesforce BAA as of current guidance
Org needs 10-year audit trail for PHI fieldsEnable Shield Field Audit Trail; configure retention to 10 years on all PHI fieldsStandard Field History Tracking retains only 18 months — insufficient for HIPAA and many state medical records laws
Client asks if Shield alone makes them HIPAA compliantProvide Shield-to-HIPAA safeguard gap analysis; identify non-Shield requirements (MFA, access controls, risk assessment, workforce training, incident response)Shield covers encryption at rest, audit trail, and event logging but does not address administrative or all technical safeguards
PHI must be shared with external partner via Experience CloudDesign sharing rules, guest user access controls, and data encryption; verify Experience Cloud is BAA-covered in executed agreementGuest user misconfiguration is a leading PHI exposure vector in Experience Cloud
Org uses Salesforce Sandbox for development/testingUse synthetic or de-identified data in Sandbox unless Sandbox is explicitly covered in the BAASandbox environments may not be covered under all BAA versions

Step-by-step instructions for an AI agent or practitioner architecting a HIPAA-compliant Salesforce org:

  1. Validate BAA coverage first. Obtain the signed BAA. Extract the covered product list. Cross-reference against the full org product inventory (platform edition, add-ons, AppExchange packages). Produce a BAA gap register listing every product not covered. Do not proceed to technical design until gaps are resolved or explicitly accepted with a risk treatment decision.
  2. Conduct PHI field inventory. Working with the health data team, enumerate all objects that will store any of the 18 HIPAA-defined PHI identifiers. Record object name, field name, data type, field label, and the HIPAA identifier category. This inventory drives the SPE encryption policy, FAT configuration, and access control design.
  3. Design the Shield control stack. For each PHI field, assign an SPE encryption scheme (deterministic vs. probabilistic). Identify functional conflicts (formula fields, external IDs, SOQL sorting) and re-architect those query patterns. Configure FAT retention to 10 years on all PHI fields. Confirm Event Monitoring transaction security policies capture login, report, and data export events for PHI-bearing objects. Document the key management approach (tenant secret vs. BYOK).
  4. Design non-Shield technical safeguards. Enforce MFA for all users accessing PHI. Apply least-privilege profile and permission set architecture — users should access only the minimum necessary PHI. Configure automatic session timeout. Define Named Credentials or OAuth flows for integration users — do not embed credentials in PHI-touching integration code. Review Connected App policies for external data consumers.
  5. Document administrative safeguard controls. Produce or reference the organization's risk assessment document mapping Salesforce org controls to HIPAA Security Rule requirements. Confirm workforce training program covers Salesforce-specific PHI handling. Define incident response runbook including Salesforce Event Monitoring alert thresholds and the 60-day breach notification clock.
  6. Validate architecture against HIPAA Security Rule safeguards matrix. Run scripts/check_hipaa_compliance_architecture.py against org metadata. Complete the architecture review checklist below. Produce the HIPAA controls specification artifact for the covered entity's compliance documentation package.
  7. Establish ongoing operational controls. Set up Event Monitoring log export to a SIEM or secure log store. Configure Shield Key Management rotation schedule. Schedule quarterly BAA coverage reviews when new products or AppExchange packages are added. Assign a designated compliance reviewer role in the org.

Review Checklist

Run through these before marking a HIPAA compliance architecture design complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. SPE breaks formula fields and SOQL ORDER BY silently — Enabling SPE on a field used in a formula field causes the formula to return a blank or error result rather than a compile-time failure. Similarly, SOQL queries with ORDER BY on an SPE-encrypted field fail at runtime. Audit all formula fields and SOQL references to candidate PHI fields before enabling encryption.
  2. Event Monitoring logs are transient by default — EventLogFile records are retained for only 1 day (hourly logs) or 30 days (daily logs) unless the org has purchased Event Log File Storage or is streaming logs to an external system. Without active log export, audit trail data required for HIPAA incident investigation may be unavailable. Configure log export before go-live.
  3. BYOK key deletion is irreversible data destruction — Shield BYOK allows customers to control key material. Destroying a BYOK key permanently renders all data encrypted under that key unreadable — there is no recovery path. BYOK is appropriate for regulatory key control requirements, not routine key rotation. Establish strict key lifecycle governance before enabling BYOK.
  4. Re-encryption jobs can cause org performance degradation — Enabling SPE on a field that already contains data triggers an asynchronous bulk re-encryption job. In large orgs (millions of records), this can saturate async job queues, slow page loads, and affect integration throughput for hours. Plan SPE enablement during a maintenance window with monitoring.
  5. Guest user access ignores sharing rules for certain object types — Experience Cloud guest users with access to Health Cloud objects can sometimes access PHI through indirect object relationships even when direct access is restricted. Always run a guest user access audit using the Salesforce Org Security Health Check and the Guest User Sharing Rules report before go-live.

Output Artifacts

ArtifactDescription
BAA scope mapTable mapping every Salesforce product and AppExchange package to BAA coverage status (covered / gap / ISV addendum required)
PHI field inventoryComplete catalog of PHI fields across all objects, including HIPAA identifier category and SPE encryption scheme assignment
HIPAA controls specificationHIPAA Security Rule safeguard to Salesforce control mapping matrix, identifying gaps and remediation owners
Shield configuration guideSPE field-by-field encryption policy, FAT retention settings, and Event Monitoring policy configuration
Risk registerNon-Shield HIPAA requirements with implementation status and evidence references for the covered entity's risk assessment
Architecture decision recordFormal ADR documenting BAA scope, product boundaries, PHI storage decisions, and key management approach

Package files