HIPAA Security Rule Technical Safeguards Guide (2025): § 164.312 Access Controls, Encryption Standards, Audit Controls, MFA Requirements, and the 2023 NPRM Changes
The HIPAA Security Rule's technical safeguards define precisely how systems containing ePHI must be configured — not at a general policy level, but at the level of encryption algorithms, authentication mechanisms, and audit log requirements. SaaS companies serving healthcare customers must implement these requirements as business associates, and the 2023 NPRM proposes converting most "Addressable" specifications to Required.
"Addressable" ≠ Optional: The OCR has repeatedly stated that "addressable" does not allow an entity to skip implementation without justification. Encryption of ePHI at rest and in transit — both technically Addressable — is routinely cited as a required control in OCR resolution agreements and is functionally Required for any device that accesses a network or leaves a controlled physical environment.
§ 164.312 Technical Safeguard Implementation Specifications
* "Addressable" but effectively Required per OCR enforcement pattern and 2023 NPRM
| CFR Section | Specification | R / A | Implementation |
|---|---|---|---|
| § 164.312(a)(1) | Unique User Identification | Required | Unique account per user; no shared accounts; SSO with user-level audit trail |
| § 164.312(a)(2)(ii) | Emergency Access Procedure | Required | Break-glass accounts with dual-approval and full audit logging |
| § 164.312(a)(2)(iii) | Automatic Logoff | Addressable | 15-min timeout (workstations); 5-min (high sensitivity); mobile MDM-enforced |
| § 164.312(a)(2)(iv) | Encryption at Rest | Addressable* | AES-256; effectively Required for any device leaving controlled environment; satisfies breach safe harbor |
| § 164.312(b) | Audit Controls | Required | SIEM; 6-year log retention; immutable logs; access, query, and change events logged |
| § 164.312(c)(2) | Authentication of ePHI | Addressable | Checksums; SHA-256 hashing; database integrity constraints; backup verification |
| § 164.312(d) | Person/Entity Authentication | Required | MFA (effectively Required under 2023 NPRM); NIST AAL2 minimum for ePHI systems |
| § 164.312(e)(1) | Transmission Security (general) | Required | TLS 1.2 minimum; TLS 1.3 preferred; disable SSL/TLS 1.0/1.1; strong cipher suites only |
| § 164.312(e)(2)(ii) | Encryption in Transit | Addressable* | TLS 1.2+; SFTP for bulk transfer; encrypted email or secure portal for ePHI email; satisfies breach safe harbor |
Contract Risk — $97
Scan Your Business Associate Agreement or HIPAA Security Policy
Upload your Business Associate Agreement (BAA), HIPAA-compliant SaaS agreement, or information security policy. BizLegal AI reviews for required BAA content elements (45 CFR § 164.504(e)), encryption commitments (AES-256 at rest / TLS 1.2+ in transit), breach notification SLA (60 days vs best practice 24-72 hours), subcontractor BAA chain obligations, right to audit provisions, permitted use and disclosure limitations, ePHI return/destruction at termination, Security Rule compliance representations, and indemnification for HIPAA Security Rule violations.
Scan Your BAA or HIPAA Policy →Frequently Asked Questions
What are the three categories of HIPAA Security Rule safeguards, and what does each cover?
The HIPAA Security Rule (45 CFR Part 164, Subpart C) was promulgated under the Health Insurance Portability and Accountability Act of 1996 and the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009. It requires covered entities (health care providers, health plans, healthcare clearinghouses) and their business associates to implement administrative, physical, and technical safeguards to protect electronic protected health information (ePHI). ePHI is individually identifiable health information that is created, received, maintained, or transmitted in electronic form — it is the subset of PHI that triggers the Security Rule. The Security Rule (unlike the Privacy Rule) applies ONLY to ePHI, not to paper records or verbal communications. Understanding the three safeguard categories is essential for any SaaS company providing services to covered entities or business associates. Administrative Safeguards (§ 164.308): the administrative safeguards are the largest and most policy-intensive category. They require a security management process (risk analysis and risk management — the most critical HIPAA requirements), a security officer, workforce training, access management procedures, and contingency planning. Key administrative safeguard requirements: (a) Security Management Process (§ 164.308(a)(1)) — Required: the entity must conduct a risk analysis to identify all reasonably anticipated risks to ePHI, and implement a risk management program to reduce risks to a reasonable and appropriate level. The risk analysis is the foundational HIPAA requirement — the OIG and OCR have made clear that failure to conduct a risk analysis is the most commonly cited finding in HIPAA audits. (b) Sanction Policy (§ 164.308(a)(1)(ii)(C)) — Required: written policies for sanctioning workforce members who violate security policies. (c) Workforce Security (§ 164.308(a)(3)) — Required: authorization and supervision procedures for workforce access to ePHI; workforce clearance procedures. (d) Information Access Management (§ 164.308(a)(4)) — Required: policies for authorizing access to ePHI; isolating healthcare clearinghouse functions; access establishment and modification procedures (Addressable). (e) Security Awareness Training (§ 164.308(a)(5)) — Required: periodic security updates and training for all workforce members; Addressable: protection from malicious software, login monitoring, password management training. (f) Contingency Plan (§ 164.308(a)(7)) — Required: data backup plan, disaster recovery plan, emergency mode operation plan; Addressable: testing and revision of contingency plan, applications and data criticality analysis. Physical Safeguards (§ 164.310): physical access controls for workstations and electronic media containing ePHI. Key requirements: (a) Facility Access Controls (§ 164.310(a)(1)) — Addressable: contingency operations procedures, facility security plan, access control and validation procedures, maintenance records. (b) Workstation Use (§ 164.310(b)) — Required: policies for appropriate workstation use and functions. (c) Workstation Security (§ 164.310(c)) — Required: physical safeguards for all workstations that access ePHI (privacy screens, locked offices, automatic screen locks). (d) Device and Media Controls (§ 164.310(d)(1)) — Required: disposal procedures for ePHI on electronic media; media re-use procedures; Addressable: accountability for hardware and electronic media movement; data backup and storage before movement. Technical Safeguards (§ 164.312): the most specific and technology-oriented safeguards — the focus of this guide. See the detailed FAQs below. Required vs Addressable — the most misunderstood HIPAA distinction: some implementation specifications are "Required" — the covered entity or business associate must implement them (no flexibility). Others are "Addressable" — the entity must assess whether the specification is a reasonable and appropriate safeguard given its risk analysis, size, and capabilities. If it is appropriate, the entity must implement it. If it is not appropriate, the entity must document why and implement an equivalent alternative measure. "Addressable" does NOT mean optional. The OCR has repeatedly stated that "addressable" does not mean an entity can simply choose not to implement it without justification. Addressable specifications that are commonly appropriate but not implemented (particularly encryption for certain devices) are among the most frequently cited findings in OCR audits.
What does § 164.312 Technical Safeguards require, and what are the specific implementation specifications?
The Technical Safeguards standard (45 CFR § 164.312) contains 5 standards with a total of 9 implementation specifications (4 Required, 5 Addressable). These specifications govern how technology systems that create, receive, maintain, or transmit ePHI must be configured and operated. Standard 1 — Access Control (§ 164.312(a)(1)): the entity must implement technical policies and procedures allowing only authorized persons or software programs to access ePHI. (a) Unique User Identification (§ 164.312(a)(2)(i)) — REQUIRED: assign a unique name or number for identifying and tracking user identity. Every user who accesses systems containing ePHI must have a unique identifier. Shared accounts are prohibited — each user's actions must be traceable to that specific individual. (b) Emergency Access Procedure (§ 164.312(a)(2)(ii)) — REQUIRED: establish and implement procedures for obtaining necessary ePHI during an emergency. The entity must have a process for emergency access that does not leave ePHI inaccessible in a crisis. (c) Automatic Logoff (§ 164.312(a)(2)(iii)) — ADDRESSABLE: implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. Industry standard: 15-minute timeout for workstations accessing ePHI; shorter timeouts (5 minutes) for high-sensitivity environments (emergency departments). (d) Encryption and Decryption (§ 164.312(a)(2)(iv)) — ADDRESSABLE: implement a mechanism to encrypt and decrypt ePHI. The ADDRESSABLE designation here is one of the most misunderstood aspects of HIPAA. Encryption of ePHI at rest on devices (laptops, mobile devices, portable storage) is addressable — but the OCR has consistently found that for any device that leaves a controlled environment, encryption is the appropriate and reasonable measure. OCR Resolution Agreements consistently include ePHI encryption requirements. For cloud-based SaaS companies: encryption at rest (AES-256 on RDS databases, S3 buckets, EBS volumes) and in transit (TLS 1.2+ minimum, TLS 1.3 preferred) should be treated as effectively Required. Standard 2 — Audit Controls (§ 164.312(b)): REQUIRED: implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit controls require: event logging (user login/logout events, successful and failed access attempts, ePHI queries, ePHI updates and deletions, privilege escalation, administrative actions); log integrity (audit logs must not be modifiable or deletable by ordinary users — separate log storage, immutable log solutions like AWS CloudTrail Lake or a SIEM with write-once storage); log retention (HIPAA does not specify a minimum retention period, but OCR guidance and NIST 800-66 Rev. 2 recommend at least 6 years for HIPAA documentation — many organizations apply 6-year log retention to audit logs); audit log review (logs must be regularly reviewed for anomalous access patterns; automated alerting on unusual ePHI access behaviors). Standard 3 — Integrity Controls (§ 164.312(c)(1)): the entity must implement policies and procedures to protect ePHI from improper alteration or destruction. (a) Mechanism to Authenticate ePHI (§ 164.312(c)(2)) — ADDRESSABLE: implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Practical implementation: database checksums, file hashing (SHA-256) for ePHI files at rest, write-once storage for backup copies, digital signatures for transmitted ePHI. Standard 4 — Person or Entity Authentication (§ 164.312(d)): REQUIRED: implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. Authentication implementations evaluated: passwords (alone, likely insufficient — see below), MFA (strongly recommended and effectively required under 2023 NPRM), biometrics, smart cards, unique session tokens, certificate-based authentication. NIST SP 800-63B guidance on authentication assurance levels: for systems containing sensitive health data (which ePHI is by definition), NIST 800-63B recommends Authenticator Assurance Level 2 (AAL2), which requires MFA. The 2023 HIPAA Security Rule NPRM proposed making MFA effectively required (see the FAQ on the 2023 NPRM below for details). Standard 5 — Transmission Security (§ 164.312(e)(1)): the entity must implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. (a) Integrity Controls (§ 164.312(e)(2)(i)) — ADDRESSABLE: implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of. Hash verification, TLS with certificate verification, digital signatures on ePHI transmissions. (b) Encryption in Transit (§ 164.312(e)(2)(ii)) — ADDRESSABLE: implement a mechanism to encrypt ePHI whenever deemed appropriate. As with at-rest encryption, this Addressable designation does not mean optional. OCR has stated that transmitting ePHI over open networks (the internet) without encryption is inappropriate. TLS 1.2 is the minimum; TLS 1.3 is preferred for all ePHI transmission over the internet. Implementation specifics: disable SSL 3.0, TLS 1.0, and TLS 1.1; require TLS 1.2 or 1.3; use strong cipher suites (AES-128 or AES-256 in GCM mode); verify certificates. SFTP or equivalent for bulk ePHI file transfers between covered entities and business associates.
What are the HIPAA encryption standards, and what does "encryption makes ePHI unusable, unreadable, and indecipherable" mean for safe harbor?
HIPAA's encryption framework is built around two regulatory documents: the HIPAA Breach Notification Rule's "safe harbor" and HHS guidance on encryption and decryption of ePHI. Understanding the encryption standard is critical because it determines whether a data breach must be reported — a properly encrypted dataset that is stolen does NOT trigger breach notification if the encryption meets HHS standards. The Breach Notification Rule Encryption Safe Harbor: under 45 CFR § 164.402, an "acquisition, access, use, or disclosure of PHI" does not constitute a "breach" requiring notification if: the ePHI is "not unsecured" — meaning it has been rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption that meets HHS guidance standards. The safe harbor turns on whether the encryption satisfies the HHS guidance published in April 2009 (updated in subsequent guidance): Encryption standards for ePHI at rest: ePHI stored on storage media is considered secure if it is encrypted using an algorithm approved by the National Institute of Standards and Technology (NIST) in FIPS 140-2. The specific algorithms approved include: AES-128, AES-192, AES-256 (all acceptable, but AES-256 is the current industry standard for health data); Triple DES (legacy — still in FIPS 140-2 but deprecated for new implementations); RSA (for key encryption, not typically used for bulk data encryption). In practice: AES-256 in GCM mode (authenticated encryption) is the current standard for ePHI at rest. It satisfies both the HIPAA safe harbor and NIST recommendations. For databases: AWS RDS with AES-256 encryption, Azure SQL Database with Transparent Data Encryption (TDE), Google Cloud SQL with at-rest encryption — all satisfy the standard. For S3 buckets: SSE-S3 (AES-256) or SSE-KMS (AES-256 with KMS key management). Key management: the encryption is only as strong as the key management. NIST 800-57 Part 1 provides key management guidance. Key rotation (annual), separation of duty for key access, audit logging of key usage, and HSM (Hardware Security Module) use for high-sensitivity environments are best practices. Encryption standards for ePHI in transit: ePHI in transit is considered secure if encrypted using the TLS (Transport Layer Security) protocol with the cipher suites and key exchange algorithms approved in NIST guidelines. Current standard: TLS 1.2 with AES-128-GCM or AES-256-GCM cipher suites is the minimum acceptable standard. TLS 1.3 is preferred — it eliminates weak cipher suites, provides forward secrecy by default, and has faster handshake performance. TLS 1.0 and 1.1 are deprecated and should be disabled. Encryption for email containing ePHI: unencrypted email is NOT a secure transmission channel for ePHI. If a covered entity or business associate sends ePHI via email: (a) the email must be encrypted end-to-end using PGP, S/MIME, or a secure email gateway with TLS enforcement; OR (b) the ePHI must be accessed through a secure portal rather than transmitted in the email body; OR (c) the individual recipient has specifically requested email delivery and has been warned of the risks (individual right to access by requested means). Email services that only offer transport-layer encryption (TLS between mail servers) without end-to-end encryption are insufficient for ePHI email unless the recipient and sender both control both endpoints and enforce TLS. Gmail, Outlook, and standard SMTP are NOT sufficient for ePHI in the email body. Secure messaging platforms used in healthcare (Klara, TigerConnect, Imprivata Cortext): these platforms are designed for ePHI and satisfy transmission security requirements. Unencrypted ePHI texted via standard SMS (even between clinical staff) is a HIPAA violation. Mobile device encryption: all mobile devices used to access ePHI must be encrypted. iOS with AES-256 (default for all modern iPhones) and Android with AES-256 (enabled by default on Android 10+) satisfy the standard. Mobile Device Management (MDM) policies must enforce full-disk encryption on all devices that can access ePHI.
What are the most common HIPAA Security Rule violations that the OCR has cited in audits and enforcement actions, and what are the penalties?
The HHS Office for Civil Rights (OCR) has published results from three rounds of HIPAA audits (2011-2012, 2016-2017) and its Phase 3 audit protocol. OCR enforcement actions and resolution agreements provide the most useful data on what actually triggers enforcement. Common HIPAA Security Rule violations in OCR enforcement actions: Violation 1 — Failure to conduct or update a risk analysis: the most frequently cited HIPAA violation in OCR audits and enforcement. The risk analysis requirement (§ 164.308(a)(1)(ii)(A)) requires a thorough, accurate, and comprehensive assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Companies that have never done a formal risk analysis, or that conducted one 5+ years ago without updating it for significant system changes, are the primary targets. Resolution agreements for risk analysis failures have ranged from $25,000 (small providers) to $5.1 million (large health systems). Violation 2 — No business associate agreement (BAA) with a vendor who accesses ePHI: a covered entity must have a BAA with every business associate (vendor, contractor, cloud service provider) who creates, receives, maintains, or transmits ePHI on the covered entity's behalf. Common failure: using a cloud vendor (AWS, Google, Microsoft) without executing their HIPAA Business Associate Agreement; using a SaaS vendor (Salesforce, Google Workspace, Slack) with ePHI present without a BAA. Notable enforcement: cloud service providers who sign BAAs become business associates — AWS, Microsoft Azure, and Google Cloud all have HIPAA BAA programs. Violation 3 — No encryption on portable devices containing ePHI: unencrypted laptops, USB drives, and backup tapes containing ePHI are the most common vehicle for breach notifications and have triggered enforcement in many cases. Resolution agreements for unencrypted portable device breaches: Advocate Medical Group ($5.55M for stolen unencrypted laptops), multiple smaller providers ($100K-$500K range for single laptop thefts). Violation 4 — Impermissible access to ePHI by workforce members (snooping): workforce members who access the ePHI of patients who are not their own (celebrity health records, family members, colleagues) without a treatment, payment, or operations purpose. The covered entity's failure to have audit log review procedures that would detect this snooping is a security rule violation. Violation 5 — Failure to implement a contingency plan and test backups: the contingency plan requirements (§ 164.308(a)(7)) require a data backup plan (tested) and disaster recovery plan. Companies that maintain backups but have never tested restoration procedures have an unverified contingency plan. Violation 6 — Failure to properly terminate access after workforce member departure: same as CC6.3 in SOC 2 — terminated employees retaining ePHI system access is a frequently cited finding. Violation 7 — Risk analysis limited in scope (not enterprise-wide): some entities conduct risk analyses only for specific systems rather than all ePHI across all systems, locations, and business units. OCR requires enterprise-wide risk analysis covering all systems, all physical locations, and all forms of ePHI. HIPAA penalty tiers (2023 inflation-adjusted): The HHS has four tiers of civil money penalties, based on culpability: Tier 1 — Did Not Know ($127-$63,973 per violation, $1,919,173 annual cap): the covered entity did not know and, by exercising reasonable diligence, would not have known of the violation. Tier 2 — Reasonable Cause ($1,280-$63,973 per violation, $1,919,173 annual cap): the violation was not due to willful neglect and was corrected within 30 days. Tier 3 — Willful Neglect — Corrected ($12,794-$63,973 per violation, $1,919,173 annual cap): willful neglect but the violation was corrected within 30 days. Tier 4 — Willful Neglect — Not Corrected ($63,973+ per violation, $1,919,173 annual cap): willful neglect and the violation was not corrected within 30 days. For "repeat" violations — violations of the same provision in different calendar years — the $1.9M annual cap is applied per year of violation. A 3-year violation of the same provision can yield up to $5.7M in aggregate penalties. State AG enforcement: state attorneys general also have authority to enforce HIPAA under HITECH. State AG settlements have been reached in several states. In some states, HIPAA violations also trigger state health data privacy law claims, which may have separate penalty structures.
What did the 2023 HIPAA Security Rule NPRM propose, and when are the changes expected to take effect?
On December 27, 2023, HHS published a Notice of Proposed Rulemaking (NPRM) to substantially revise the HIPAA Security Rule for the first time since 2005. The NPRM (88 Fed. Reg. 89062) proposed significant changes to technical safeguard requirements and would eliminate much of the "addressable vs required" distinction that has created compliance ambiguity for 20 years. Status as of 2025: the NPRM closed its public comment period in March 2024. As of July 2026, a final rule has not been issued. The NPRM remains in the regulatory pipeline, but the timing and final form of the rule remain uncertain given regulatory review processes and potential administration changes. Key proposed changes in the 2023 NPRM: (1) Eliminating "addressable" designation for most technical safeguards: the NPRM proposed removing the Required/Addressable distinction for many specifications, converting previously Addressable specifications (including encryption) to Required. This would formalize what has been functionally required for years through OCR enforcement. (2) MFA required for all access to ePHI: the NPRM proposed requiring multi-factor authentication for all electronic access to ePHI, with limited exceptions for emergency access situations. This would eliminate the current ambiguity about whether MFA is required for HIPAA compliance. The practical effect for most healthcare vendors: if you are not using MFA for all user access to systems containing ePHI, the 2023 NPRM signals that this gap will be a Required violation under a final rule. Begin implementing MFA now regardless of when the rule becomes final. (3) Vulnerability scanning and penetration testing required: the NPRM proposed requiring regulated entities to conduct vulnerability scans every 6 months and penetration tests annually. Many healthcare organizations currently conduct these on an informal or infrequent basis — the NPRM would impose mandatory schedules. (4) Network segmentation required: separation of electronic systems that contain ePHI from other electronic systems. This is current best practice for health tech companies but not currently an explicit HIPAA requirement. (5) Encryption required for all ePHI at rest and in transit: the NPRM proposed converting the Addressable encryption specifications to Required, removing any basis for not encrypting ePHI (at rest or in transit). (6) Annual risk analysis required (currently unspecified frequency): the NPRM proposed requiring risk analysis on an annual basis (or more frequently when system changes occur), removing ambiguity about how often the risk analysis must be updated. (7) Written incident response plan required: the NPRM proposed requiring a documented incident response plan (currently addressed under contingency planning but not explicitly required as a standalone document). (8) Group health plan requirements: specific new requirements for health plan sponsors regarding separation of ePHI from employer data. What should B2B SaaS companies and health tech vendors do now: (a) Treat the proposed changes as future requirements and begin implementing MFA, encryption, annual risk analysis, quarterly vulnerability scanning, and annual penetration testing now. (b) The NPRM reflects OCR enforcement priorities — even under current rules, OCR will cite failure to encrypt or use MFA as violations under the addressable specification analysis. (c) Update BAA templates to reflect NPRM expectations where feasible. (d) Review and update incident response plans to meet the proposed explicit requirements. (e) If not already doing so, begin conducting formal annual risk analyses, documenting them thoroughly, and maintaining documentation for 6 years as required by the HIPAA documentation retention standard.
How do HIPAA Security Rule requirements interact with a SaaS company's SOC 2 compliance program, and what is the optimal dual-compliance approach?
Many SaaS companies serving healthcare customers pursue both HIPAA compliance (as a business associate) and SOC 2 Type 2 certification simultaneously. The frameworks significantly overlap — but they differ in important ways that affect how a combined program should be designed. Framework comparison — where they converge: SOC 2 CC6 (Logical and Physical Access) ↔ HIPAA § 164.312(a) (Access Control): both require unique user identification, access provisioning/deprovisioning, vendor access management, and MFA. A mature CC6 program that satisfies SOC 2 will largely satisfy the HIPAA Technical Safeguard access control standard. SOC 2 CC7 (System Operations) ↔ HIPAA § 164.308(a)(6)/(8) and § 164.312(b) (Audit Controls): both require security event logging, anomaly detection, vulnerability management, and incident response. SIEM, audit logs, and vulnerability scanning serve both frameworks. SOC 2 CC8 (Change Management) ↔ HIPAA § 164.308(a)(8) (Evaluation): both require documented change management procedures and periodic review of security controls. SOC 2 CC9 (Risk Mitigation) ↔ HIPAA § 164.308(a)(1) (Security Management) and § 164.308(b) (Business Associate Contracts): both require risk assessment and vendor management. Where they diverge: HIPAA risk analysis: HIPAA requires a comprehensive, documented risk analysis covering all ePHI — a specific artifact that SOC 2 does not require. The HIPAA risk analysis is a standalone required documentation item. HIPAA documentation retention (6 years): HIPAA requires retaining documentation (policies, procedures, records of activities, risk analysis) for 6 years from creation or the date it was last in effect. SOC 2 audit evidence typically has shorter retention requirements. HIPAA business associate agreements: HIPAA requires BAAs with all vendors who access ePHI — this has no direct SOC 2 equivalent (though SOC 2 CC9.2 covers vendor management). HIPAA does not require a specific certification: unlike PCI DSS (which requires QSA assessment), HIPAA does not require a third-party certification. The SOC 2 audit does not replace HIPAA compliance — it demonstrates security controls that support HIPAA compliance. Minimum Necessary standard: HIPAA requires using/disclosing only the minimum ePHI necessary for the stated purpose. SOC 2 does not have a direct minimum-necessary equivalent. BAA in the SaaS company context: when a SaaS company serves covered entities, it is a business associate for HIPAA purposes. The SaaS company must: (a) sign a HIPAA Business Associate Agreement (BAA) with each covered entity customer before receiving any ePHI; (b) implement HIPAA Security Rule safeguards for ePHI it receives from covered entities; (c) sign BAAs with its own subcontractors who will access ePHI (AWS, database vendors, monitoring tools if they receive ePHI). The SaaS company's SOC 2 Type 2 report is the primary evidence of Security Rule compliance that a covered entity customer can review — it shows the audited controls operate effectively. Optimal dual-compliance program design: (a) Build a single unified control framework (UCF) mapping each control to both SOC 2 TSC references and HIPAA § references. (b) A single access review process satisfies both CC6.3 (SOC 2) and HIPAA workforce security. (c) A single SIEM and audit logging program satisfies both CC7.2 (SOC 2) and HIPAA § 164.312(b). (d) Add HIPAA-specific artifacts ON TOP of the SOC 2 program: (i) HIPAA risk analysis document (standalone document, updated annually); (ii) BAA template and BAA registry; (iii) HIPAA Privacy Rule policies (SOC 2 doesn't cover the Privacy Rule); (iv) Minimum necessary standard policy; (v) HIPAA training records distinct from general security awareness. (e) Compliance automation platforms (Vanta, Drata) support HIPAA + SOC 2 dual frameworks in a single platform, with unified control evidence mapped to both frameworks. HIPAA-specific gap from SOC 2: the main gap is the risk analysis. Most SOC 2 programs include a risk assessment (CC3), but the SOC 2 risk assessment is often at a higher level than the HIPAA-required comprehensive ePHI risk analysis. The HIPAA risk analysis must identify and document specific threats and vulnerabilities to ePHI in each system, location, and device type where ePHI is present.