Skip to main content

HIPAA mapping

HIPAA applies to any Salesforce deployment that touches Protected Health Information (PHI). In practice that means Health Cloud builds, regulated systems-integrator deployments at payers and providers, and any custom-built app that stores patient or member records. The Security Rule (45 CFR Part 164, Subpart C) defines the technical, administrative, and physical safeguards a covered entity or business associate must implement.

This page maps the technical safeguards subpart (45 CFR § 164.312) onto the Vulkro detectors that produce evidence for them.

For the non-Salesforce half of a HIPAA audit (web app, API, mobile, storage), see the general-scanner HIPAA page.

Run it​

vulkro-sf scan ./force-app --compliance hipaa
vulkro-sf scan ./force-app --compliance-pack hipaa -o hipaa-readiness.html

Technical safeguards covered​

StandardTitleVulkro detector(s) that feed it
§ 164.312(a)(1)Access Controlprofiles-permsets (least-privilege enforcement), security-settings (session timeout)
§ 164.312(a)(2)(i)Unique User Identificationprofiles-permsets (shared-credential detection via SSO / no-MFA flags)
§ 164.312(a)(2)(iii)Automatic Logoffsecurity-settings (sessionTimeout enforcement)
§ 164.312(a)(2)(iv)Encryption and Decryptiondetectors/apex (crypto misuse, hardcoded keys)
§ 164.312(b)Audit Controlssecurity-settings (EventLogFile retention), org-status (Field Audit Trail enablement)
§ 164.312(c)(1)Integritydetectors/apex (CRUD/FLS enforcement on write paths)
§ 164.312(d)Person or Entity Authenticationsecurity-settings (SAML signature algorithm, MFA enforcement)
§ 164.312(e)(1)Transmission Securitysecurity-settings (requireHttps), connected-apps (OAuth scope review)
§ 164.312(e)(2)(i)Integrity Controls (in transit)connected-apps (callback URL is https://), named-credentials (TLS endpoints)
§ 164.312(e)(2)(ii)Encryption (in transit)security-settings (TLS minimum version), named-credentials

Per-standard detail​

§ 164.312(a)(1) Access Control​

The standard: implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.

In a Salesforce org with PHI in custom objects (PatientCase__c, MemberRecord__c, Health Cloud PatientCaseFlowEvent__c), Access Control is enforced through profiles, permission sets, and sharing rules. Vulkro emits over-privilege findings any time a non-admin profile carries ModifyAllData, ViewAllData, or sObject-level View All on a sObject the PII map classifies as PHI.

Companion check: session timeout. If a clinician walks away from a laptop and a session stays open for 24 hours, the access control is in name only. The detector flags any sessionTimeout exceeding the documented HIPAA baseline.

§ 164.312(a)(2)(i) Unique User Identification​

Implementation specification (required): assign a unique name and number for identifying and tracking user identity.

Shared credentials defeat this control. Vulkro emits findings for:

  • Profiles configured for SSO with the "Is Single Sign-On Enabled" flag combined with a missing MFA requirement (the SSO flag without MFA is the documented breakage path).
  • API-only users with widely-shared session-key usage patterns (org-status connector signal).

§ 164.312(a)(2)(iii) Automatic Logoff​

Implementation specification (addressable): implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

The detector enforces a documented sessionTimeout ceiling on every profile. Health Cloud and regulated SI deployments typically pick 15 minutes for clinical users, 60 minutes for back-office. The detector flags any value above the baseline.

§ 164.312(a)(2)(iv) Encryption and Decryption​

Implementation specification (addressable): implement a mechanism to encrypt and decrypt electronic protected health information.

In an Apex codebase, this is the crypto-misuse detector: MD5 / SHA1 on a PHI field, hardcoded keys, deprecated cipher modes, insecure random-source usage, and unauthenticated symmetric encryption.

§ 164.312(b) Audit Controls​

The standard: implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

The Salesforce-shaped evidence:

  • EventLogFile retention configured to at least 30 days (the org-pull detector reads the current retention setting).
  • Field Audit Trail enabled on every PHI sObject (the org-status connector confirms enablement).
  • Login History retention is non-zero.

The detector flags any retention setting below the documented baseline.

§ 164.312(c)(1) Integrity​

The standard: implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

The technical control on the Salesforce side is CRUD/FLS enforcement on Apex write paths. An Apex method that updates a PHI sObject without checking field-level security can write a value the calling user is not authorized to write. The Apex detector emits a finding for every write path lacking enforcement.

§ 164.312(d) Person or Entity Authentication​

The standard: implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

Vulkro checks:

  • MFA enforcement on every login route (session settings).
  • SAML signature algorithm (SHA-1 is flagged; SHA-256 minimum).
  • SAML assertion encryption.
  • Connected App OAuth flow review (User-Agent flow on a confidential client is flagged).

§ 164.312(e)(1) Transmission Security​

The standard: implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

Vulkro covers:

  • SecuritySettings.requireHttps enforcement on every login route and Site / Experience Cloud surface.
  • Connected App callback URLs on https://.
  • Named Credential endpoints on https://.
  • TLS minimum version (TLS 1.2 baseline; 1.0 / 1.1 flagged).

Health Cloud sObject coverage​

The PII map detector inventories PHI fields by sObject. The default coverage set:

  • Standard Health Cloud objects: PatientCaseFlowEvent__c, HealthcareProvider__c, HealthCondition__c, CarePlan__c.
  • Health Cloud OmniStudio / FlexCard data sources that surface PHI.
  • Common custom-PHI patterns: any custom object with fields named MRN__c, DOB__c, Diagnosis__c, Medication__c, SSN__c, MemberID__c.

The output is a sensitive-SObject inventory ranked by PHI-field count, which doubles as the Article 30-equivalent Records of Processing Activities for HIPAA's risk analysis (§ 164.308(a)(1)(ii)(A)).

See the PII map detector for the inventory format and how to extend it for custom Health Cloud schemas.

The Business Associate Agreement reminder​

A scanner emits technical evidence. It does not sign a BAA.

A BAA is the contract between a covered entity and a business associate that establishes:

  • The permitted and required uses and disclosures of PHI.
  • That the business associate will use appropriate safeguards.
  • That the business associate will report unauthorized uses or disclosures.
  • Subcontractor flow-down obligations.

The BAA is a person's deliverable. Vulkro produces the evidence that your appropriate safeguards (§ 164.312 technical safeguards) are in place. The BAA itself is yours to draft, negotiate, and sign.

What's NOT covered​

The Security Rule has three subparts. Vulkro covers the technical safeguards subpart (§ 164.312). It does not cover:

  • § 164.308 Administrative Safeguards: security management process, workforce training, contingency plan, evaluation.
  • § 164.310 Physical Safeguards: facility access, workstation use and security, device and media controls.
  • § 164.314 Organizational Requirements: BAAs, group health plan requirements.
  • § 164.316 Policies and Procedures and Documentation Requirements: written policies, retention, availability.

Those need a Security Officer (§ 164.308(a)(2)), written policies, a risk analysis (§ 164.308(a)(1)(ii)(A)), workforce training records, an incident response plan, and signed BAAs with every subcontractor that touches PHI. A scanner does not produce those artifacts.