Introduction
AWS Security Assurance Services, LLC has issued new guidance for implementing HIPAA Security Rule Technical Safeguards (45 CFR §164.312) on AWS. This guidance addresses current requirements and anticipates changes from the January 2025 Notice of Proposed Rulemaking, which will make encryption, multi-factor authentication for all ePHI access, and asset inventory mandatory. The document includes a shared responsibility matrix, ePHI boundary architecture patterns, and a foundational checklist for covered entities and business associates. This isn't just another compliance document; it's a crucial tool for understanding where your responsibilities begin under the shared model, reducing audit risk.
Timeline of Changes
- Current state: HIPAA Security Rule Technical Safeguards (§164.312) define five standards and nine implementation specifications. Many specifications are Addressable, often misinterpreted as optional.
- January 2025: The proposed rule will eliminate Addressable designations and add requirements for network segmentation, configuration management, anti-malware protection, patch management, software removal, and enhanced incident response.
- June 2026: Final rule not yet published.
- AWS recommendation: Treat all specifications as Required for new workloads now, regardless of final rule timing.
Common Control Failures
Organizations often fail at three control boundaries:
Unclear ePHI scope definition. You need to define your ePHI boundary before implementing technical controls. Without this, you risk encrypting unnecessary data and exposing actual ePHI. Your auditor will require data flow diagrams. If you can't trace ePHI from ingestion through storage to transmission, you're not ready for a HIPAA assessment.
Shared responsibility confusion. The responsibility matrix maps each §164.312 specification to what AWS manages versus what you must configure. Most breaches stem from customer-side misconfigurations. AWS provides encryption capabilities, but you must enable them, manage the keys, and prove correct implementation.
Treating Addressable as optional. Many organizations skip Addressable specifications or mark them as "not applicable" without a risk assessment. The proposed rule closes this loophole. If you're treating Addressable specifications as suggestions, you're accumulating technical debt that will become a compliance gap once the final rule is published.
HIPAA Security Rule Requirements
The Technical Safeguards standard (§164.312) includes five core requirements:
Access control (§164.312(a)(1)) requires unique user identification, emergency access procedures, automatic logoff, and encryption/decryption mechanisms. Encryption, currently Addressable, will be Required for all ePHI at rest and in transit under the proposed rule. Implement it now as Required.
Audit controls (§164.312(b)) require mechanisms to record and examine activity in systems containing ePHI. Use CloudTrail, CloudWatch, or equivalent logging with retention periods that support breach investigation. The proposed rule adds configuration management and asset inventory requirements.
Integrity (§164.312(c)(1)) requires mechanisms to protect ePHI from improper alteration or destruction. This includes transmission integrity (§164.312(e)(2)(i)) and authentication (§164.312(d)). Transmitting ePHI without TLS 1.2 or higher is non-compliant under the proposed rule.
Person or entity authentication (§164.312(d)) requires verifying access seekers' identities. The proposed rule mandates multi-factor authentication for all ePHI access. If you're still using username/password authentication for production ePHI systems, you're behind.
Transmission security (§164.312(e)(1)) requires measures to guard against unauthorized access during electronic transmission. The proposed rule requires encryption in transit, removing the current Addressable status.
Action Items for Your Team
Map your ePHI boundary this quarter. Use the AWS guidance reference architecture to trace every ePHI data flow. Document ingestion points, storage locations, processing systems, and transmission paths. If you can't draw this on a whiteboard, you can't defend it in an audit.
Run the foundation checklist before configuring individual controls. The guidance includes prerequisite recommendations. Ensure AWS Organizations is configured, service control policies are enforced, and IAM roles are properly scoped before implementing encryption or MFA.
Implement the proposed rule requirements now. Enable encryption at rest and in transit for all ePHI. Require MFA for all ePHI access. Implement network segmentation, configuration baselines, and automated patch management. Delaying these actions creates a gap you'll scramble to close under audit pressure.
Build the shared responsibility matrix into your control documentation. For each §164.312 specification, document what AWS provides, what you configured, and what evidence proves correct implementation. Your auditor won't accept "AWS handles that" as an answer. Provide screenshots, configuration exports, and policy documents.
Test your audit trail before you need it. Enable CloudTrail for all ePHI-adjacent services. Configure log retention that supports the 72-Hour Notification Requirement investigation window and state-specific breach notification timelines. Run a simulated breach investigation to verify you can reconstruct access patterns and data flows from your logs.
Update your incident response plan for the proposed specifications. The NPRM adds explicit requirements for incident response and breach notification procedures. If your plan doesn't include network segmentation changes, malware response, and emergency patch deployment, you're not ready for the updated rule.
The guidance is available now. Your next audit will expect you to have read it.
