On AWS, the account boundary does most of the HIPAA work

Illustrative only. A start-up sells video visits to US clinics. Its booking app, database and file store run on AWS. Video sessions use a third-party video provider, error tracking is a separate tool, and the product team wants dashboards on visit data. Everything began life in one AWS account shared with marketing.

Only two rows are settled by AWS at all. The others depend on other vendors and on design choices.

AWS calls its agreement the Business Associate Addendum and handles it in AWS Artifact, the console area for agreements and audit reports. You can accept it for a single account, or, from the management account of AWS Organizations, for every account in the organisation, including accounts created later.

AWS publishes a reference list of HIPAA eligible services and adds to it over time. The list changes, so we do not reproduce it here. Read the current one before each design decision, and record which version you checked.

• A service that is not on the list can still run in the account. It must never receive PHI: no patient fields in its inputs, names, tags or logs.
• Metadata leaks too. Object keys, queue names and resource tags built from patient names put PHI where you did not plan it.
• A new managed service that the team wants to try needs a check against the list first, not after the pilot.

Mixing patient data with marketing, experiments and build tooling in one account means every person and role in that account is in scope. Separate accounts shrink the scope and let you apply stricter rules where ePHI lives without slowing everyone else down.

1. ACCT.1
   ePHI workload accountProduction systems that store or process patient data, and nothing else.
2. ACCT.2
   Log archive accountReceives logs from every account. Few people can read it; nobody can delete from it.
3. ACCT.3
   Security tooling accountWhere alerts and posture findings are reviewed, away from the workloads.
4. ACCT.4
   Non-PHI accountsDevelopment, marketing and experiments, seeded only with synthetic data.
5. ACCT.5
   Organisation-level guardrailsNew in 2022Policies set from the top, for example limiting regions or stopping logging from being switched off.

In AWS Organizations, service control policies can cap what any role in a member account may do, which turns a written rule such as approved regions only into one that the platform enforces.

Several AWS storage services now encrypt new data at rest by default with keys AWS manages. That covers the stolen-disk case. It does not separate who can read the data from who can administer it. For ePHI, most teams move to customer managed keys in AWS Key Management Service (KMS).

Key policy

States which roles may use a key and which may manage it. Keep the two lists apart.

Key per data class

Separate keys for the booking database, documents and backups, so one revocation does not stop everything.

Organisation trail

An AWS CloudTrail trail for the whole organisation, delivered to the log archive account.

Data-event logging

Control-plane logs show who changed settings. Reads of patient files need data events switched on where you need them.

• Addendum on record. Accepted in Artifact, with the date and the accounts it covers.
• Eligible-service check. Each service holding PHI matched to the current list, with the date checked.
• Root user sealed. Hardware MFA, no access keys, use alerts.
• Federated sign-in. People sign in through your identity provider with MFA; no long-lived user keys.
• No public data. Public access blocked on storage, and no public snapshots or database endpoints.
• Managed keys. Customer managed keys on ePHI stores and backups, with separate admin and use roles.
• Logs centralised. Organisation trail to the log archive, protected from deletion, reviewed by a named person.
• Restore tested. A recent, timed restore of the booking database, with the result recorded.

The shared-responsibility model itself, and what applies on any platform, is on the general HIPAA in the cloud page.

Sources: 45 CFR 160.103 and 45 CFR Part 164, Subpart C (Security Rule), in particular 164.308(b), 164.312(a) and 164.312(b); HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing; AWS public HIPAA compliance page; AWS Artifact user guide on managing agreements.