AWS Control Tower and HIPAA: how to govern multi-account ePHI workloads

Earth from orbit representing cloud-scale governance

AWS Control Tower and HIPAA is a practical pairing for healthtech and healthcare teams that need multi-account AWS governance without inventing a landing zone from scratch. Control Tower helps you stand up a governed AWS Organizations structure with baseline guardrails—but it does not, by itself, make you HIPAA compliant.

HIPAA still requires you to scope ePHI, execute BAAs, implement Security Rule safeguards, run risk analysis, and prove that controls operate over time. Control Tower’s value is operational: account isolation, preventive policy, detective monitoring, and a repeatable way to provision environments that match your compliance design.

This guide covers:

What Control Tower can and cannot do for HIPAA programs
BAAs, HIPAA-eligible services, and shared responsibility on AWS
Landing zone patterns for isolating ePHI workloads
How to map guardrails to Security Rule safeguards and collect evidence

Cloud security team locking down infrastructure

GIF via GIPHY

Related guides:

Key takeaways

Control Tower is a governance accelerator—not a HIPAA certification. It helps you enforce account structure and guardrails; your policies, BAAs, risk analysis, and operating procedures still drive compliance.
Isolate ePHI early. Put production PHI workloads in dedicated accounts/OUs with tighter SCPs than sandbox or non-PHI environments.
Sign the AWS BAA before PHI arrives, and only place ePHI in HIPAA-eligible services you have configured under that agreement.
Pair preventive and detective controls. SCPs and Control Tower guardrails block risky actions; Config, CloudTrail, Security Hub, and access reviews prove controls worked.
Evidence needs owners and cadence. Landing zone screenshots alone rarely satisfy audits—map configs to Security Rule safeguards and refresh proof on a schedule.

What AWS Control Tower is (and is not) for HIPAA

AWS Control Tower helps organizations set up and govern a secure, multi-account AWS environment using AWS Organizations, Account Factory, and a catalog of preventive and detective guardrails. Typical outputs include:

A landing zone with shared accounts (for example, log archive, audit/security tooling, and networking)
Organizational units (OUs) for grouping workload accounts
Service control policies (SCPs) and Config rules that limit drift
A consistent account provisioning path for new teams and environments

For HIPAA programs, that matters because many Security Rule failures in the cloud are structural: PHI in shared sandboxes, overly broad IAM, missing logging, or unmanaged accounts created outside security review.

What Control Tower is not:

A substitute for a HIPAA risk assessment
Automatic coverage for every AWS service you enable
Proof that your application-layer access controls, retention, or breach processes work
A reason to skip BAAs, workforce training, or vendor due diligence

Treat Control Tower as the foundation layer of your AWS HIPAA architecture. Application security, data minimization, and GRC workflows still sit on top.

Shared responsibility, BAAs, and HIPAA-eligible services

On AWS, HIPAA follows the same shared responsibility pattern as other regulated workloads:

Responsibility area	Typically AWS	Typically your organization
Physical data center & hardware	Yes	No
Hypervisor / managed service baseline	Yes (service-dependent)	Configuration and use still yours
BAA / HIPAA-eligible service selection	Provides eligible services under BAA	Decide what to use; keep PHI in scope
Identity, encryption keys, network rules	Tools provided	Design, enforce, review
Application access to ePHI	No	Yes
Logging retention, IR, risk analysis	Partial tooling	Ownership and operating procedures

Before ePHI lands in AWS:

Execute a business associate agreement (BAA) with AWS (and with any other vendors that create, receive, maintain, or transmit PHI).
Inventory HIPAA-eligible services you plan to use (compute, storage, databases, messaging, analytics). Non-eligible services should not hold PHI.
Document data flows—ingress, storage, processing, backups, logs, support tooling, and egress.
Confirm region and architecture choices against your risk analysis and customer contracts.

For broader cloud HIPAA context, see HIPAA compliance in cloud-based healthcare.

Design a HIPAA-minded Control Tower landing zone

A strong HIPAA landing zone starts with intentional boundaries: who can create accounts, where PHI is allowed, what is blocked by default, and which shared services own logging and security tooling.

Recommended account structure for ePHI

A common pattern for healthtech / BA organizations:

Account / OU purpose	Typical contents	PHI allowed?
Management / Control Tower	Organizations, Control Tower, SCPs	No (prefer no PHI)
Log archive	Centralized CloudTrail, Config, VPC Flow Logs	Logs may contain identifiers—treat carefully
Security / Audit	Security Hub, GuardDuty, detective tooling	Prefer minimized PHI
Shared services / networking	Transit, DNS, shared endpoints	Usually no PHI
Non-PHI / sandbox OU	Experiments, POCs	No
Staging OU	Pre-prod with synthetic or carefully controlled data	Prefer synthetic; if PHI, same controls as prod
Production ePHI OU	Apps, databases, queues holding PHI	Yes—tightest controls

Practical rules teams commonly adopt:

Never put production ePHI in developer personal accounts
Prefer synthetic data in lower environments whenever possible
Keep break-glass and admin paths short-lived, MFA-protected, and logged
Separate CI/CD roles so pipelines cannot casually dump PHI to unmanaged buckets

OUs, SCPs, and preventive guardrails

Preventive controls reduce the chance that a well-meaning engineer creates an unrecoverable HIPAA gap. Examples of SCP / guardrail themes that often align with HIPAA risk reduction:

Deny leaving the approved regions for ePHI accounts
Deny disabling CloudTrail, Config, or security services in PHI OUs
Restrict creation of public access on storage and databases unless explicitly approved
Limit root user usage and require MFA for privileged identities
Constrain which IAM principals can attach broad administrator policies in ePHI accounts
Block unapproved marketplace or account-sharing patterns that bypass your BAA inventory

Control Tower’s built-in guardrails are a starting catalog—not a complete HIPAA control set. Extend them with organization-specific SCPs informed by your risk analysis and Security Rule priorities.

Detective controls and continuous monitoring

Detective layering is where audit evidence usually comes from:

AWS Config rules for encryption, public exposure, MFA, and required tags (for example, data-class=ephi)
CloudTrail organization trails to the log archive account
Security Hub / findings aggregation for misconfigurations
Access reviews of IAM roles and federated groups that can reach PHI accounts
Change tickets for SCP exceptions and emergency access

If a control only exists in a slide deck, it will not survive customer questionnaires or OCR scrutiny. Wire detections to owners and response SLAs.

Map Control Tower capabilities to HIPAA Security Rule safeguards

Use this decision table to connect landing zone features to Security Rule themes. It is not a one-to-one legal mapping—HIPAA is risk-based—but it helps engineering and compliance speak the same language.

HIPAA Security Rule theme	Control Tower / AWS governance lever	What “good” looks like
Access control	Account isolation, SSO permission sets, SCPs	Least privilege by OU; no shared root; MFA for admins
Audit controls	Org CloudTrail + Config + centralized logs	Immutable log archive; retention documented; review workflow
Integrity	Change control + Config drift detection	Unauthorized changes alerted; exceptions tracked
Transmission security	Network controls + TLS requirements	Private connectivity patterns; no cleartext PHI paths
Person or entity authentication	Federated IdP + MFA policies	Unique identities; no long-lived shared keys for humans
Contingency planning	Multi-AZ design + backup accounts/policies	Backup encryption, restore tests, documented RTO/RPO
Risk analysis & management	Guardrail exceptions + findings triage	Risk register ties cloud findings to remediation owners

Encryption deserves explicit treatment: Control Tower can help enforce encryption requirements via policies and Config, but you still choose key management, rotation, and access to plaintext. See HIPAA encryption requirements.

Implementation checklist for GRC and cloud teams

Use this as a joint runbook between Compliance/GRC, Security, and Cloud Platform:

Confirm scope — Which products, accounts, and vendors touch ePHI?
Execute BAAs — AWS first; then subprocessors in the data path.
Stand up / harden Control Tower — Landing zone, log archive, security account, baseline guardrails.
Create ePHI OU(s) — Stricter SCPs than non-PHI OUs.
Provision workload accounts via Account Factory — No ad-hoc account creation for PHI systems.
Enable detective stack — Org trail, Config recorder, Security Hub (or equivalent), alerting into IR.
Tag and inventory — Resources that store or process PHI; keep the inventory current.
Document exceptions — Temporary SCP exceptions with owner, expiry, and compensating controls.
Run access reviews — Especially for roles that can read production databases or logs with identifiers.
Tabletop IR + restore tests — Prove contingency and incident procedures with cloud realities (keys, accounts, regions).
Refresh risk analysis — After major architecture or OU policy changes.
Export evidence — Config snapshots, SCP versions, trail settings, BAA records, training, and review results.

Software teams implementing product controls on top of this foundation can follow the HIPAA software development checklist.

Owners, evidence, and audit cadence

HIPAA programs fail when “the cloud team owns AWS” and “compliance owns HIPAA” never meet. Assign named owners:

Control area	Typical owner	Evidence examples	Cadence
Landing zone & SCPs	Cloud Platform / Security Engineering	Control Tower OU map, SCP JSON versions, change tickets	Quarterly + on change
BAA & service eligibility	Legal / Compliance + Security	Signed BAA, eligible service list, architecture diagram	Ongoing + annual refresh
Identity & access	Identity / Security	SSO permission sets, MFA reports, access review exports	Quarterly + offboarding
Logging & monitoring	Security Operations	Trail config, log retention, alert runbooks, sample tickets	Monthly health check
Encryption & KMS	Security / Platform	KMS policies, Config compliance, key admin list	Monthly
Incident & contingency	Security + Engineering	IR plan, tabletop notes, restore test reports	Semiannual
Risk analysis	Compliance / Security	Risk assessment report, remediation tracker	At least annually + major changes

When auditors or enterprise customers ask “how do you govern AWS for PHI?”, your answer should be a story with artifacts: OU design → preventive policies → detective monitoring → owners → recent evidence—not a product logo.

Common mistakes when using Control Tower for HIPAA

Assuming Control Tower equals HIPAA compliant. Guardrails help; they do not replace BAAs, policies, training, or application controls.
Putting PHI in the wrong OU. Sandbox freedom and production PHI controls cannot share the same loose SCPs.
Centralizing logs without access discipline. Log archives can contain identifiers; treat access as sensitive.
Exception sprawl. Temporary SCP denials that never expire become permanent risk.
Ignoring non-AWS tools. Support desks, analytics warehouses, and ticketing systems often become shadow PHI stores.
Evidence collected once at launch. Landing zone build docs go stale; Config and access reviews must stay current.
Skipping risk analysis updates after Account Factory growth or new HIPAA-eligible services.

Streamline AWS Control Tower and HIPAA with SecureSlate

Control Tower governs AWS accounts. SecureSlate helps you govern the compliance program that sits around those accounts—policies, ownership, vendor/BAA tracking, recurring reviews, and audit-ready evidence.

With SecureSlate, you can:

Map Security Rule safeguards to owners and living evidence (not one-off screenshots)
Track BAAs, vendors, and subprocessors that sit beside your AWS estate
Run recurring workflows like access reviews and policy acknowledgements
Keep risk assessment tasks and remediation status visible across GRC and engineering
Export a coherent trail for customer security reviews and audits

Get started for free to turn AWS Control Tower governance into a continuous HIPAA compliance workflow.

FAQ

Does AWS Control Tower make us HIPAA compliant?

No. Control Tower improves multi-account governance and can enforce helpful guardrails, but HIPAA compliance depends on your scope, BAAs, risk analysis, safeguards, and ongoing evidence—across AWS and non-AWS systems.

Do we need AWS Control Tower to run HIPAA workloads on AWS?

No. Many organizations implement Organizations, SCPs, and logging manually. Control Tower is useful when you want a standardized landing zone and account factory. The HIPAA outcomes matter more than the provisioning product.

Can we store ePHI in every account under Control Tower?

You typically should not. Use dedicated OUs/accounts for ePHI with stricter preventive and detective controls, and keep sandboxes free of PHI.

Is a BAA still required if we use Control Tower?

Yes, if AWS will create, receive, maintain, or transmit PHI on your behalf under HIPAA. Control Tower does not replace the BAA requirement, and you should still limit PHI to HIPAA-eligible services covered by that agreement.

What evidence do auditors usually want for AWS HIPAA programs?

Commonly: architecture/data-flow diagrams, BAA records, encryption and logging configurations, access review results, risk analysis, incident/contingency documentation, and proof that guardrails or equivalent policies were in place during the period under review.

How often should we review Control Tower guardrails for HIPAA?

Review after material architecture changes, and on a fixed cadence (commonly quarterly for SCP/guardrail effectiveness and access, with a fuller risk analysis at least annually). Align cadence to your risk and customer commitments.

Disclaimer (legal note)

This article is for general informational purposes and is not legal, privacy, security, or audit advice. HIPAA obligations depend on your role (covered entity, business associate, or subcontractor), facts, and contracts. AWS service eligibility and shared responsibility details can change—verify current AWS documentation and consult qualified counsel and security professionals before making compliance decisions.