The Problem
Most HIPAA-on-AWS guides try to be exhaustive and end up unactionable. Two hundred controls drawn from the full Security Rule, with no help separating “you must have this” from “you should have this eventually.”
Engineering teams in early-stage healthcare companies don’t have time for two hundred controls. They need the minimal technical posture that satisfies the Security Rule without delaying the product roadmap by a quarter.
There is one.
The Approach
HIPAA on AWS reduces to twelve technical controls grouped into four areas. Have these in place and you have a defensible technical posture. Administrative and physical safeguards layer on top later, but auditors ask about the technical layer first, and engineering owns it end-to-end.
Sign the BAA, then use only eligible services
Before anything else, sign the AWS Business Associate Addendum from the AWS Artifact console. The BAA is what makes AWS a HIPAA business associate; without it, you have no legal coverage for storing or transmitting PHI on the platform.
The BAA only covers AWS’s defined list of “HIPAA-eligible services” (currently around 150). Use a service outside that list to handle PHI and you’ve stepped outside the BAA. The list shifts over time, so treat eligibility as a runtime check, not a one-time decision.
Account architecture: separate workloads from logs from audit
Run PHI workloads in a dedicated AWS account. Run a separate account for centralized logs. Run a third account as the audit/security tooling landing zone. The three-account split is the minimum that gives you the four properties HIPAA cares about:
- Production-data access is narrow and traceable.
- Logs cannot be tampered with by the same identities that can touch production.
- Audit tooling has a stable home with its own access boundary.
- Account-level blast radius is contained.
Use AWS Organizations with Service Control Policies (SCPs) to enforce account boundaries. The single highest-leverage SCP is “deny removal of CloudTrail in any account.”
Identity: MFA, no root, scoped roles
Three rules: every human has MFA on their console access; the root account is locked away and not used for anything except billing; humans assume cross-account roles via IAM Identity Center (formerly AWS SSO) rather than holding long-lived IAM users.
Service identities use IAM roles with the narrowest possible scope. If your CI pipeline needs to deploy to S3 and invalidate a CloudFront distribution, its role gets exactly those two actions. Not s3:*. Not cloudfront:*.
Data: encrypt at rest, encrypt in transit, manage your keys
Everything storing PHI must be encrypted at rest with AWS KMS. The default AWS-managed key is acceptable for the MVP posture; customer-managed keys (CMKs) with annual rotation become valuable when you’re large enough that key-access auditing matters.
In transit: TLS 1.2 minimum on every endpoint. Disable HTTP entirely at the load-balancer level. mTLS for service-to-service is worth doing eventually, but TLS termination at the load balancer with private VPC routing is enough for the MVP.
Observability: log everything, then make the logs untouchable
CloudTrail organization-wide trail logging to the log-archive account, S3 destination configured with Object Lock in compliance mode. Object Lock is what turns “logs you keep” into “logs an auditor will believe.” It prevents anyone, including the AWS root user, from deleting logs within the retention period.
VPC Flow Logs into the same archive account. Application logs into CloudWatch Logs with one-year retention minimum. The MVP retention rule: longer than your average incident-discovery window plus six months. Six years is HIPAA’s general recommendation; one year is the operational floor.
Backup: it’s part of compliance, not separate from it
AWS Backup with cross-region copy for any service holding PHI. The Security Rule’s contingency-plan requirement calls for both backup procedures and disaster recovery. A documented annual restore drill closes the loop on both.
The Template
The twelve-control map below is what the MVP posture looks like, scored against your environment. Each row gets a yes / no / partial. Where you have partial coverage, write a one-line note describing what’s missing. The whole document fits on a page.
Prefer the interactive version? The HIPAA-Readiness Self-Assessment walks you through the same twelve controls in 3 minutes, computes your score, and emails you a per-category breakdown.
| # | Area | Control | Service / mechanism |
|---|---|---|---|
| 1 | Legal | BAA signed | AWS Artifact |
| 2 | Legal | Only HIPAA-eligible services touch PHI | Documented list |
| 3 | Architecture | Workloads / logs / audit separated into 3+ accounts | AWS Organizations |
| 4 | Architecture | SCPs prevent CloudTrail removal | SCP s-DenyCloudTrailDelete |
| 5 | Identity | MFA required on all human console access | Identity Center policy |
| 6 | Identity | Root account locked + monitored | Alarm on root usage |
| 7 | Identity | Service roles least-privileged | IAM access analyzer |
| 8 | Data | All PHI data stores encrypted at rest | KMS |
| 9 | Data | All endpoints TLS 1.2+ | ELB / CloudFront / API Gateway |
| 10 | Observability | CloudTrail org-wide → log-archive account with Object Lock | CloudTrail + S3 Object Lock |
| 11 | Observability | VPC Flow Logs centralized | VPC + S3 |
| 12 | Backup | Cross-region backup + annual restore drill | AWS Backup |
Run through it for your environment. Anywhere you score no, decide one of three things: implement it this quarter, accept and document the gap, or escalate it as a compliance risk.
What’s Deliberately Not Here
The MVP skips: SIEM, intrusion detection (GuardDuty is a “should,” not a “must”), Macie for PHI discovery, Web Application Firewall rules, third-party CSPM tooling. All add value. None are required for a defensible HIPAA posture on day one.
Layer them on when the audit cycle starts to feel painful. Until then, the twelve above are the work.