HIPAA Compliance on AWS: Technical Safeguards and the BAA Requirement

HIPAA compliance on AWS is a combination of legal agreement, service selection, and technical configuration. The legal component — the Business Associate Agreement (BAA) — establishes AWS's obligations around Protected Health Information (PHI). The technical component — configuring services according to the HIPAA Security Rule's technical safeguards — is your responsibility. Neither is sufficient alone: a signed BAA without proper technical controls doesn't make you compliant, and proper technical controls without a BAA means you're using AWS without the necessary legal framework for PHI processing.

This guide covers both requirements, with emphasis on the technical configurations that address the Security Rule's requirements for systems handling PHI.

The Business Associate Agreement

Under HIPAA, a Business Associate Agreement is required whenever a covered entity shares PHI with a service provider that handles that PHI on its behalf. AWS, as a cloud provider processing PHI for healthcare organizations, is a business associate. You must sign a BAA with AWS before processing PHI in your AWS environment.

To obtain and sign the AWS BAA, navigate to the AWS Artifact console and accept the AWS Business Associate Addendum. This is a self-service process — AWS doesn't need to review your application or approve your use case to provide the BAA. Once accepted, the agreement applies to all current and future use of HIPAA-eligible services in your account.

The BAA covers only HIPAA-eligible services. Not all AWS services are HIPAA-eligible. Before processing PHI in any service, verify that the service is on the HIPAA Eligible Services Reference (a page maintained by AWS and updated as new services are added). Core services — EC2, S3, RDS, Lambda, KMS, CloudTrail — are HIPAA-eligible. Newer or more experimental services may not be.

The Security Rule's Technical Safeguards

HIPAA's Security Rule (45 CFR § 164.312) specifies technical safeguards that must be in place for electronic PHI. The four main categories:

Access Control (§ 164.312(a)(1)): Implement technical policies and procedures to allow only authorized persons access to ePHI. On AWS, this means IAM policies with least privilege for all users and roles that can access PHI-containing resources, unique user identification (no shared credentials), automatic logoff from idle sessions, and encryption/decryption of ePHI (covered under encryption below).

Audit Controls (§ 164.312(b)): Implement hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. AWS CloudTrail provides this for API activity; CloudWatch Logs and S3 access logging for resource-level access. Enable all relevant logging before processing PHI and retain logs for a minimum of 6 years (HIPAA's required retention period for documentation, though many organizations retain for 7 years to provide margin).

Integrity Controls (§ 164.312(c)(1)): Protect ePHI from improper alteration or destruction. Enable CloudTrail log file integrity validation so that tampering with audit logs is detectable. Use S3 Object Lock (WORM mode) for archival PHI data to prevent modification. Enable versioning on S3 buckets containing ePHI so that deletions are recoverable.

Transmission Security (§ 164.312(e)(1)): Guard ePHI against unauthorized access during transmission. Require TLS 1.2 or later for all API and web traffic. Enforce TLS in ALB listeners. Configure RDS to require SSL for database connections. Never allow PHI to transit unencrypted networks.

Encryption at Rest for PHI

While HIPAA doesn't explicitly mandate encryption at rest (it's an "addressable" rather than "required" specification), the HHS Office for Civil Rights strongly encourages it as the most effective protection against breach. In practice, any HIPAA implementation that doesn't encrypt PHI at rest would struggle to pass a compliance review.

Enable encryption for all storage services containing PHI:

• S3: enable SSE-KMS on buckets containing PHI (SSE-S3 also meets the technical requirement, but SSE-KMS provides key management controls and audit trails)
• RDS: enable storage encryption when creating the database (cannot be added to existing unencrypted databases — requires a snapshot and restore to an encrypted instance)
• EBS volumes: enable encryption by default at the account level so all new volumes are encrypted automatically
• DynamoDB: enabled by default, but verify the table uses KMS encryption for explicit key management

Minimum Necessary Access and Audit Logging

HIPAA's minimum necessary principle requires limiting PHI access to the minimum needed to perform a function. Implement this through:

Separate IAM roles for different access levels: read-only roles for reporting and analytics, read-write roles for application functions, administrative roles only for specific administrative tasks. Don't give all application functions the same role permissions — a function that reads patient records for display doesn't need write permissions.

S3 bucket policies that restrict access to specific IAM roles and principals. Enable S3 Server Access Logging or use CloudTrail data events for S3 to log every object access. Auditors will ask who accessed PHI records — these logs are how you answer that question.

Database-level audit logging through RDS enhanced monitoring and Performance Insights. For MySQL/MariaDB, enable the audit log plugin; for PostgreSQL, use the pgaudit extension. These logs capture which queries accessed which records, supplementing the AWS API-level logs from CloudTrail.

Incident Response for PHI Breaches

HIPAA requires notifying affected individuals within 60 days of discovering a breach, notifying HHS, and (for breaches affecting more than 500 individuals in a state) notifying prominent media outlets. Your incident response plan must specifically address PHI breach scenarios with these notification requirements.

Configure GuardDuty and CloudTrail alerting to detect unauthorized access to PHI resources. Unusual S3 access patterns, unrecognized IAM principals accessing PHI databases, and API calls from unexpected geographic locations are all signals worth alerting on. Early detection gives you time to contain the breach before the 60-day notification clock becomes critical.

Related Reading

• SOC 2 compliance on AWS — overlapping controls between SOC 2 and HIPAA
• CloudTrail best practices — audit logging that satisfies HIPAA requirements
• S3 encryption — protecting PHI stored in S3
• Compliance risk scoring — tracking HIPAA control coverage

FAQ

Do I need HIPAA compliance if I only handle de-identified data?

Properly de-identified data — meeting the standards of 45 CFR § 164.514(a) — is not PHI and is not subject to HIPAA requirements. However, de-identification is harder than it sounds. Data must remove all 18 HIPAA-specified identifiers, or a qualified statistical expert must certify that the risk of re-identification is very small. Quasi-identifiers like date of birth combined with ZIP code and gender can re-identify data even with direct identifiers removed. Get a HIPAA attorney to review your de-identification methodology before relying on it.

What's the difference between a covered entity and a business associate?

Covered entities are health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically. Business associates are organizations that create, receive, maintain, or transmit PHI on behalf of a covered entity. As a healthcare SaaS provider, your customers (hospitals, practices, health plans) are likely covered entities; you're their business associate. You need BAAs with your customers for your customer's PHI and a BAA with AWS for your use of AWS to process that PHI.

Which AWS services are NOT HIPAA-eligible?

AWS publishes the HIPAA Eligible Services Reference listing all covered services. Services not on the list cannot be used to store or process PHI. Common services that are not (or were not until recently) HIPAA-eligible include some newer AI/ML services, certain analytics services, and some developer tools. Always check the current list rather than relying on memory — services are added regularly as AWS completes the compliance certification process.