---
title: HIPAA on AWS: The Compliance Lead's Audit-Ready Checklist
description: An audit-prep checklist for Compliance Leads, Security Officers, and CISOs — BAA execution, documented Security Risk Assessments, workforce training, audit cadence, and the evidence packages OCR investigators expect when they show up.
url: https://www.factualminds.com/blog/hipaa-on-aws-complete-compliance-checklist/
datePublished: 2026-01-25T00:00:00.000Z
dateModified: 2026-04-29T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: hipaa, compliance, aws-security, healthcare, governance
---

# HIPAA on AWS: The Compliance Lead's Audit-Ready Checklist

> An audit-prep checklist for Compliance Leads, Security Officers, and CISOs — BAA execution, documented Security Risk Assessments, workforce training, audit cadence, and the evidence packages OCR investigators expect when they show up.

> **Looking for the engineering build guide?** This checklist covers the **governance and audit-prep** side of HIPAA — policies, BAAs, documented risk assessments, and the evidence package an OCR investigator expects. If you're an architect or platform engineer wiring up encryption, KMS, VPC isolation, and IaC controls, read [How to Implement a HIPAA-Compliant Architecture on AWS](/blog/how-to-implement-hipaa-compliant-architecture-aws/) instead.

This checklist is written for the person who **owns HIPAA compliance** — the designated Security Officer, the Compliance Lead, the CISO, or the founder pulling double duty until you hire one. The work here isn't about which AWS service to encrypt with which KMS key (that's the engineering guide). It's about the program, the paperwork, and the cadence: signing the BAA, documenting your Security Risk Assessment in the format OCR expects, executing workforce training, running access reviews, and assembling evidence so that an audit (or a breach) doesn't surprise you.

If you're starting from scratch, work through Sections 1–3 first (administrative safeguards, account structure, IAM governance) — most HIPAA failures we see are governance gaps, not encryption gaps. AWS provides the tools and services needed for compliance under the shared responsibility model, but configuring and **documenting** them correctly is your responsibility. For a broader look at [cloud compliance services](/services/cloud-compliance-services/) covering HIPAA, SOC 2, PCI DSS, and more, see our full compliance offering.

This checklist is based on our experience building HIPAA-compliant environments for healthcare organizations, health-tech startups, and any business that handles Protected Health Information (PHI) on AWS.

## Understanding HIPAA on AWS

### The Shared Responsibility Model for HIPAA

AWS is HIPAA-eligible, but that does not make your workload HIPAA-compliant by default. AWS is responsible for the security of the cloud (physical infrastructure, hypervisors, managed service security). You are responsible for security in the cloud (configuration, access controls, encryption, and application-level security).

**What AWS guarantees:** Physical data center security, network infrastructure, and the underlying security of HIPAA-eligible services.

**What you must configure:** Encryption, access controls, logging, monitoring, incident response, and administrative safeguards.

### The Business Associate Agreement (BAA)

Before using AWS for PHI, you must have a Business Associate Agreement (BAA) in place with AWS. The BAA establishes the responsibilities of both parties for protecting PHI.

**How to get the BAA:** Sign the AWS BAA through the AWS Artifact console. This is a self-service process — no sales call or negotiation required. The BAA covers all HIPAA-eligible AWS services used in accounts that are part of your AWS Organization.

## The HIPAA Compliance Checklist

### 1. Administrative Safeguards

- [ ] **Execute the AWS BAA** — Sign the Business Associate Agreement through AWS Artifact before processing any PHI
- [ ] **Document your Security Risk Assessment** — HIPAA requires a documented risk analysis identifying potential threats to PHI
- [ ] **Assign a Security Officer** — Designate an individual responsible for HIPAA security policies and procedures
- [ ] **Create policies and procedures** — Document your organization's HIPAA policies covering access, encryption, incident response, and workforce training
- [ ] **Implement workforce training** — Ensure all employees who interact with PHI receive HIPAA awareness training annually
- [ ] **Establish Business Associate Agreements** with all third parties — Any vendor that accesses, stores, or processes PHI on your behalf needs a BAA

### 2. AWS Account and Organization Setup

- [ ] **Use AWS Organizations** — Separate HIPAA-regulated workloads into dedicated AWS accounts, isolated from non-HIPAA workloads
- [ ] **Enable AWS CloudTrail** — Organization-wide trail logging all API calls to a dedicated, tamper-proof S3 bucket in a log archive account
- [ ] **Enable AWS Config** — Record resource configurations and evaluate compliance rules across all accounts
- [ ] **Enable AWS Security Hub** — Centralized security findings aggregation with HIPAA-specific compliance checks
- [ ] **Enable GuardDuty** — Threat detection across all accounts in the Organization
- [ ] **Apply Service Control Policies** — Restrict launching resources in unauthorized Regions, prevent disabling CloudTrail, and enforce other organizational guardrails

### 3. Identity and Access Management

- [ ] **Enforce MFA for all human access** — Console users, CLI users, and root accounts must use MFA
- [ ] **Eliminate root account usage** — Root credentials should only be used for account-level tasks that require them. Enable MFA on root and store credentials securely
- [ ] **Implement least-privilege IAM policies** — No user or role should have AdministratorAccess or PowerUserAccess in HIPAA accounts
- [ ] **Use IAM roles, not access keys** — EC2 instances, Lambda functions, and ECS tasks should use IAM roles, not long-lived access keys
- [ ] **Rotate credentials regularly** — If access keys are necessary, enforce automatic rotation through Secrets Manager
- [ ] **Implement role-based access control** — Define IAM groups and roles aligned to job functions with appropriate permission boundaries
- [ ] **Enable IAM Access Analyzer** — Identify resources shared externally and unused permissions

### 4. Encryption

HIPAA requires encryption of PHI at rest and in transit. AWS provides the tools; you must configure them.

**At Rest:**

- [ ] **S3 — Default encryption enabled** (SSE-S3 or SSE-KMS with customer-managed keys)
- [ ] **EBS — Encryption enabled on all volumes** (using KMS keys)
- [ ] **RDS — Encryption enabled on all instances** (enabled at creation, cannot be added retroactively)
- [ ] **DynamoDB — Encryption enabled** (default with AWS-managed keys, or customer-managed KMS keys)
- [ ] **ElastiCache — Encryption at rest enabled** for Redis clusters
- [ ] **SQS — Server-side encryption enabled** with KMS keys
- [ ] **SNS — Message encryption enabled** for topics carrying PHI
- [ ] **Kinesis — Encryption enabled** for data streams
- [ ] **EFS — Encryption enabled** at creation
- [ ] **Backup — All backups encrypted** with the same or stricter key policies as source data

**In Transit:**

- [ ] **Enforce TLS 1.2+** for all external-facing endpoints (ALB, API Gateway, CloudFront)
- [ ] **Enforce SSL/TLS for database connections** — `rds.force_ssl` parameter enabled
- [ ] **Enforce HTTPS for S3 access** — Bucket policy denying `aws:SecureTransport` = false
- [ ] **VPC endpoints for AWS service access** — Keep traffic off the public internet for S3, DynamoDB, SQS, and other services

**Key Management:**

- [ ] **Use AWS KMS customer-managed keys** for PHI encryption — provides audit trail via CloudTrail and granular access control
- [ ] **Enable automatic key rotation** — Annual rotation for KMS keys
- [ ] **Restrict key policies** — Only authorized roles and users can use encryption keys

### 5. Network Security

- [ ] **Deploy PHI workloads in private subnets** — No direct internet access for databases, application servers, or storage
- [ ] **Use NAT Gateways for outbound internet access** from private subnets
- [ ] **Implement Security Groups with least-privilege rules** — No 0.0.0.0/0 ingress except for public-facing load balancers on ports 80/443
- [ ] **Use Network ACLs as an additional layer** — Subnet-level deny rules for defense in depth
- [ ] **Deploy AWS WAF on ALBs and CloudFront** — Protect against OWASP Top 10 attacks
- [ ] **Enable VPC Flow Logs** — Capture network traffic metadata for security monitoring and incident investigation
- [ ] **Implement VPC endpoints** — Reduce attack surface by accessing AWS services without traversing the internet

### 6. Logging and Monitoring

HIPAA requires audit controls that record and examine activity in systems containing PHI.

- [ ] **CloudTrail — Organization-wide trail** logging all management and data events to a secured, encrypted S3 bucket with object lock (immutable logs)
- [ ] **CloudWatch Logs — Application and system logs** from all PHI-processing workloads
- [ ] **VPC Flow Logs — Network activity** captured for all VPCs handling PHI
- [ ] **S3 access logging — Enabled** for all buckets containing PHI
- [ ] **RDS audit logging — Enabled** (MySQL audit log, PostgreSQL pgaudit, or SQL Server audit)
- [ ] **CloudWatch Alarms — Configured** for security-relevant events:
  - Root account login
  - IAM policy changes
  - Security Group changes
  - CloudTrail configuration changes
  - Unauthorized API calls
- [ ] **Log retention — Defined and enforced** — HIPAA requires 6-year retention for certain records. Configure CloudWatch log retention and S3 lifecycle policies accordingly

### 7. HIPAA-Eligible AWS Services

Only use HIPAA-eligible services for PHI workloads. The current list includes (but is not limited to):

| Category   | Eligible Services                                               |
| ---------- | --------------------------------------------------------------- |
| Compute    | EC2, Lambda, ECS, EKS, Fargate, Lightsail                       |
| Storage    | S3, EBS, EFS, S3 Glacier, Storage Gateway                       |
| Database   | RDS, Aurora, DynamoDB, ElastiCache, DocumentDB, Neptune         |
| Networking | VPC, Route 53, CloudFront, API Gateway, ELB, Transit Gateway    |
| Security   | IAM, KMS, Secrets Manager, GuardDuty, Security Hub, WAF, Shield |
| Analytics  | Athena, Kinesis, QuickSight, Glue, EMR                          |
| AI/ML      | SageMaker, Bedrock, Comprehend Medical, Transcribe Medical      |
| Messaging  | SES, SNS, SQS, EventBridge                                      |
| Monitoring | CloudWatch, CloudTrail, Config, X-Ray                           |

**Important:** Check the [AWS HIPAA Eligible Services page](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) for the latest list, as AWS regularly adds services.

### 8. Data Backup and Disaster Recovery

- [ ] **Automated backups enabled** for all databases (RDS, DynamoDB, Aurora)
- [ ] **Cross-Region backup replication** for disaster recovery (if RTO/RPO requirements warrant it)
- [ ] **Backup encryption** — All backups encrypted with KMS keys
- [ ] **Regular backup restoration testing** — Quarterly validation that backups can be restored successfully
- [ ] **Documented disaster recovery plan** — RPO and RTO targets defined for each PHI workload
- [ ] **AWS Backup centralized policy** — Consistent backup policies applied across all PHI data stores

### 9. Incident Response

- [ ] **Documented incident response plan** — Procedures for detecting, responding to, and reporting PHI breaches
- [ ] **Automated detection** — GuardDuty, Security Hub, and CloudWatch alarms for suspicious activity
- [ ] **Automated response** — Lambda functions triggered by GuardDuty findings for initial containment (e.g., isolating compromised instances)
- [ ] **Breach notification procedures** — Process for notifying affected individuals, HHS, and media (if applicable) within HIPAA's 60-day requirement
- [ ] **Post-incident review** — Root cause analysis and remediation after every security event

### 10. Ongoing Compliance Monitoring

- [ ] **AWS Config rules** — Automated compliance checking for encryption, public access, logging, and other HIPAA requirements
- [ ] **Security Hub HIPAA standard** — Enable the AWS Foundational Security Best Practices standard and review findings weekly
- [ ] **Quarterly access reviews** — Review IAM users, roles, and permissions quarterly to remove unnecessary access
- [ ] **Annual risk assessment** — Update your security risk analysis annually or when significant changes occur
- [ ] **Penetration testing** — Annual penetration testing of HIPAA-regulated workloads (AWS permits penetration testing with notification)
- [ ] **Vendor management** — Review BAAs and security practices of all business associates annually

## GenAI on AWS for HIPAA Workloads

Generative AI is increasingly used in healthcare applications — clinical documentation, diagnostic assistance, patient communication, and medical coding. Building GenAI into HIPAA workloads on AWS requires additional controls beyond the checklist above.

### HIPAA-Eligible GenAI Services

The following AWS AI/ML services are HIPAA eligible (under a signed BAA):

- **Amazon Bedrock** — Foundation model access (Claude, Llama 4, Titan, Nova, and others). Your prompts and completions stay within your AWS account; model providers never see your data.
- **Amazon Comprehend Medical** — PHI extraction and de-identification from clinical text. Detects 65+ PHI entity types (names, dates, SSNs, account numbers, diagnoses).
- **Amazon Transcribe Medical** — HIPAA-eligible speech-to-text for clinical conversations and dictation.
- **Amazon SageMaker** — Custom model training and inference for healthcare-specific models.

**Bedrock is HIPAA eligible** — but eligibility alone does not make your deployment compliant. You must also:

- [ ] **Execute the AWS BAA** before using Bedrock for PHI workloads (covered above)
- [ ] **Enable Bedrock Guardrails** — Configure PII/PHI detection and redaction filters to prevent PHI from appearing in model outputs. Guardrails can mask SSNs, MRNs, dates of birth, and other PHI categories automatically.
- [ ] **Use Bedrock Knowledge Bases** for RAG over clinical content — keeps retrieval within your VPC and logs all retrievals to S3 for audit
- [ ] **Enable VPC endpoints for Bedrock** — Route Bedrock API calls over AWS PrivateLink to prevent PHI from traversing the public internet
- [ ] **Log all Bedrock interactions** — Model invocation logging to S3 provides the audit trail HIPAA audit controls require
- [ ] **Apply Bedrock organizational policies** — Enforce guardrail requirements across all AWS accounts in your organization using AWS Organizations policies
- [ ] **Implement Bedrock AgentCore Identity** (for agentic workflows) — Scope AI agent permissions to minimum required access with audit trails for every agent action

### Protecting PHI in AI Workflows

The primary risk in GenAI healthcare applications is PHI leakage — patient data appearing in model responses, logs, or third-party integrations.

**Layered PHI protection approach:**

1. **Pre-processing:** Use Amazon Comprehend Medical to de-identify PHI before sending to the model when full PHI is not needed for the task
2. **Guardrails layer:** Configure Bedrock Guardrails with PHI redaction for any remaining PHI in prompts/responses
3. **Output review:** For high-stakes clinical decisions, implement human-in-the-loop review before acting on model outputs
4. **Audit logging:** All Bedrock invocations with CloudTrail + S3 logging provides the complete audit trail

> **Note:** Amazon Bedrock's compliance scope covers ISO, SOC 1/2/3, CSA STAR Level 2, GDPR, FedRAMP High, and HIPAA eligibility. For healthcare applications requiring HITRUST CSF certification, verify whether Bedrock's current compliance scope meets your HITRUST requirements.

## Common HIPAA Mistakes on AWS

### Mistake 1: Assuming the BAA Covers All Services

The AWS BAA only covers HIPAA-eligible services. If you process PHI through a non-eligible service, you are out of compliance — even with a signed BAA. Always verify that every service in your PHI data path is on the eligible services list.

### Mistake 2: Not Encrypting RDS at Creation

RDS encryption must be enabled when the instance is created. You cannot add encryption to an existing unencrypted RDS instance. The workaround is to create an encrypted snapshot, restore from it, and switch over — a process that requires downtime.

### Mistake 3: Storing PHI in CloudWatch Logs Without Encryption

CloudWatch Logs can contain PHI if your application logs include patient data. Enable KMS encryption on log groups that may contain PHI, and implement log scrubbing in your application to minimize PHI in logs.

### Mistake 4: Using Default VPCs

Default VPCs have permissive networking configurations. Always deploy HIPAA workloads in custom VPCs with intentionally designed subnets, routing, and security policies.

### Mistake 5: No Log Retention Policy

HIPAA requires retaining certain records for 6 years. Without explicit retention policies on CloudWatch Logs and CloudTrail S3 buckets, logs may be deleted prematurely or retained indefinitely (increasing storage costs).

## Getting Started with HIPAA on AWS

HIPAA compliance on AWS is achievable with the right architecture and configuration. The checklist above provides a comprehensive starting point, but every organization's compliance requirements are different based on the type of PHI handled, the applications processing it, and the regulatory environment.

Our team has built HIPAA-compliant environments for healthcare providers, health-tech startups, and organizations handling PHI in any capacity. We can help you design, implement, and validate your compliance posture.

For broader AWS security services, see our [AWS Cloud Security and Compliance](/services/aws-cloud-security/) page.

[Contact us to build your HIPAA-compliant AWS environment →](/contact-us/)

## FAQ

### Does AWS sign a Business Associate Agreement (BAA)?
Yes. The AWS BAA is self-service through AWS Artifact — sign it at the management account level and it covers all HIPAA-eligible AWS services across every account in the AWS Organization. No sales call or negotiation required. The BAA must be in place before any PHI is processed in AWS, and only services explicitly listed as HIPAA-eligible can touch PHI.

### Are all AWS services HIPAA-eligible?
No — AWS publishes the HIPAA-eligible services list and updates it quarterly. The big production services (S3, EC2, EBS, RDS, DynamoDB, Lambda, ECS, EKS, CloudWatch, KMS, Secrets Manager, Bedrock, SageMaker) are eligible. New services often take a quarter or two to get added. Use AWS Config rules to detect PHI-tagged resources running on non-eligible services and Service Control Policies to deny non-eligible service usage in HIPAA accounts.

### How often should I document a HIPAA Security Risk Assessment?
At minimum annually, plus after any significant change — new product, new vendor, new region, major architectural change, security incident, or workforce reorganization. The SRA must be documented in writing in the OCR-recognized format covering threat identification, vulnerability assessment, likelihood, impact, and risk-treatment decisions. Use the HHS SRA Tool or NIST SP 800-30 as the template; auditors want to see the methodology, not just the conclusions.

### What evidence does an OCR auditor request?
A typical OCR investigation request includes: signed BAA with AWS, the documented Security Risk Assessment and treatment plan, written policies and procedures, workforce training records with acknowledgments, IAM access reviews, CloudTrail logs covering the audit period, encryption configuration evidence, incident response logs, and Business Associate inventory with executed BAAs. Build the evidence package continuously — Audit Manager and Security Hub generate most of it automatically.

### Who must complete HIPAA workforce training?
Every workforce member with access to PHI — not just engineers. That includes customer support staff who can read tickets containing PHI, sales engineers with demo-environment access, contractors with VPN access, and any executive with admin permissions. Training must be documented, refreshed annually, and acknowledged in writing or via your HRIS. New hires must complete training before being granted PHI access.

---

*Source: https://www.factualminds.com/blog/hipaa-on-aws-complete-compliance-checklist/*
