# A Minimum-Viable HIPAA Compliance Posture for AWS

Canonical: https://kaansystems.com/library/minimum-viable-hipaa-aws
Topic: Compliance · Published: 2026-05-12 · Updated: 2026-10-29
Summary: Most HIPAA-on-AWS guides are overwhelming. The minimal posture that passes audit and lets engineering keep moving is twelve controls, grouped across account architecture, identity, data protection, and observability.

## Key takeaways

- HIPAA on AWS reduces to twelve technical controls across four areas: account architecture, identity, data protection, and observability.
- Sign the AWS Business Associate Addendum in AWS Artifact first, and keep PHI on HIPAA-eligible services only (~150 today) — treat eligibility as a runtime check, not a one-time decision.
- Separate workloads, logs, and audit tooling into at least three AWS accounts, enforced with Organizations SCPs; the highest-leverage SCP denies CloudTrail deletion.
- Encrypt PHI at rest with KMS and enforce TLS 1.2+ in transit; AWS-managed keys are fine for the minimum-viable posture.
- Ship an org-wide CloudTrail to a log-archive account with S3 Object Lock (compliance mode) so the logs are tamper-proof — even to root.
- SIEM, GuardDuty, Macie, and WAF are a should, not a must: layer them on when the audit cycle starts to hurt.

## What does enough HIPAA on AWS actually require?

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.

## Which controls are the minimum, and where do they live?

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. Most of these controls do double duty for [SOC 2 readiness](/library/soc2-for-startups-complete-guide) — the encryption, access, and tamper-proof-logging requirements overlap almost entirely — so if a SOC 2 audit is next, the HIPAA work carries straight over.

### 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:

1. Production-data access is narrow and traceable.
2. Logs cannot be tampered with by the same identities that can touch production.
3. Audit tooling has a stable home with its own access boundary.
4. 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."

```mermaid
flowchart LR
  subgraph ORG[AWS Organization · SCPs enforce boundaries]
    direction LR

    subgraph WL[Workload account]
      direction TB
      APP[Application + PHI data]
      RDS[(RDS · KMS-encrypted)]
      S3W[(S3 · PHI · KMS)]
      APP --> RDS
      APP --> S3W
    end

    subgraph LOG[Log-archive account]
      direction TB
      CT[(CloudTrail logs)]
      VPC[(VPC Flow Logs)]
      OL[S3 Object Lock<br/>compliance mode]
      CT --> OL
      VPC --> OL
    end

    subgraph AUD[Audit / security account]
      direction TB
      CFG[AWS Config]
      GD[GuardDuty]
      IAM[Identity Center]
    end

    WL -.->|"CloudTrail trail<br/>(org-wide)"| LOG
    WL -.->|"Resource snapshots"| AUD
    AUD -.->|"Read-only audit"| WL
    AUD -.->|"Read-only audit"| LOG
  end

  classDef wl  fill:#1F4A3E,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef log fill:#0d1f1a,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef aud fill:#0a1612,stroke:#2E8B6F,stroke-width:1.5px,color:#E8F5EE;
  classDef band fill:#2E8B6F0A,stroke:#2E8B6F,stroke-width:1px;
  class APP,RDS,S3W wl;
  class CT,VPC,OL log;
  class CFG,GD,IAM aud;
  class ORG,WL,LOG,AUD band;
```

### 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.

[Book a call →](https://cal.com/benrubert/30min?utm_source=library&utm_medium=article&utm_campaign=minimum-viable-hipaa-aws&utm_content=middle)

## 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.

> **Want this scored against your estate?** The [7-day Assessment](/assessment) is read-only and covers the account split, logging, and encryption on this checklist.

| # | 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.

## Frequently asked questions

**Q: What is the minimum HIPAA setup on AWS?**

A defensible minimum is twelve technical controls across four areas: account architecture (separate workload, log-archive, and audit accounts plus SCPs), identity (MFA everywhere, locked root, least-privilege roles), data (KMS encryption at rest and TLS 1.2+ in transit), and observability (an org-wide CloudTrail shipped to a tamper-proof log archive). Sign the AWS BAA before any of it.

**Q: Do I need a BAA with AWS for HIPAA?**

Yes. Sign the AWS Business Associate Addendum in AWS Artifact before you store or transmit PHI. Without it you have no legal coverage, and it only extends to AWS's HIPAA-eligible services.

**Q: Which AWS services are HIPAA-eligible?**

Only the services AWS lists as HIPAA-eligible (around 150 today) are covered by the BAA; using anything else to handle PHI steps outside it. The list changes over time, so verify eligibility as a runtime check rather than trusting a one-time decision.

**Q: How many AWS accounts do I need for HIPAA?**

At least three: a workload account for PHI, a separate log-archive account, and an audit or security account, tied together with AWS Organizations SCPs. That split gives traceable production access, tamper-proof logs, and contained blast radius.

**Q: Is AWS-managed KMS enough for HIPAA, or do I need customer-managed keys?**

AWS-managed KMS keys are acceptable for a minimum-viable HIPAA posture. Customer-managed keys with rotation become worthwhile once you are large enough that key-access auditing matters.

**Q: What HIPAA controls can I skip at first?**

SIEM, GuardDuty, Macie, WAF, and third-party CSPM tooling all add value but are not required for a defensible day-one posture. Add them when the audit cycle starts to feel painful.

Template: "Control-mapping checklist" — branded PDF at https://kaansystems.com/templates/minimum-viable-hipaa-aws.pdf

Source: https://kaansystems.com/library/minimum-viable-hipaa-aws · Work with Kaan Systems: https://kaansystems.com/contact