HIPAA on AWS and Azure: what small healthcare teams need to configure

AWS and Microsoft Azure can both be used to store and process protected health information (PHI). Neither is “HIPAA compliant” on its own, though. HIPAA compliance depends on how you configure and operate the services, and on your own policies and training. There is also no official government HIPAA certification for a cloud setup; what matters is that the required safeguards are in place and documented.

Start with the shared responsibility model

The cloud provider secures the physical data centres, hardware and core infrastructure. You are responsible for everything you configure: who has access, whether data is encrypted, what is logged, how backups work and how devices that access PHI are protected. Most cloud breaches come from the customer side of that line, such as a public storage bucket or an admin account without MFA.

1. Sign the Business Associate Addendum

Before any PHI goes into the cloud, you need a Business Associate Addendum (BAA) with the provider.

• AWS: the BAA is accepted online through AWS Artifact in the console, for a single account or for your whole organization.
• Microsoft: the HIPAA BAA is included in Microsoft’s standard product terms and data protection addendum for in-scope services, including Azure and Microsoft 365.

Also check every other vendor that touches PHI: email, backup, monitoring, ticketing and analytics tools all need their own BAA.

2. Use only eligible services for PHI

Both providers publish a list of services covered by their BAA (AWS calls them HIPAA-eligible services; Microsoft lists in-scope services). Keep PHI inside those services only. A new service your developers want to try may not be on the list yet, so make checking it part of your change process.

3. Lock down identity and access

• Require MFA for every user, with phishing-resistant methods for administrators where possible.
• Give each person their own account; no shared logins.
• Grant least privilege through roles and groups, and review access every quarter.
• On Azure and Microsoft 365, use conditional access so PHI can only be opened from compliant, managed devices.
• Remove access the same day someone leaves.

4. Encrypt data at rest and in transit

Under the HIPAA Security Rule, encryption is an “addressable” specification, but in practice it is expected, and it can matter a great deal if a breach occurs. Both clouds make it straightforward:

5. Log and monitor access

The Security Rule requires audit controls that record activity in systems containing PHI. Turn on and retain:

• AWS: CloudTrail across all regions and accounts, S3 and database access logs where needed, GuardDuty for threat detection and Security Hub to track configuration findings.
• Azure: Activity logs and resource diagnostic logs sent to a Log Analytics workspace, Microsoft Defender for Cloud, and Entra ID sign-in and audit logs.

Store logs somewhere administrators cannot quietly delete them, and set retention to match your policy. HIPAA requires policies and documentation to be kept for six years, and many organisations keep audit logs on a similar schedule.

6. Back up, and prove you can restore

A contingency plan is a required part of the Security Rule. Use AWS Backup or Azure Backup with encrypted, regular backups, keep a copy in a separate account or subscription, and turn on immutability where available so ransomware cannot delete it. Then test restores on a schedule and record the results.

7. Do the risk analysis and write it down

A documented risk analysis is required, and it is one of the first things investigators ask for after a breach. List where PHI lives, the threats to it, the safeguards in place and the gaps you are fixing. Pair it with written policies for access, incident response and breach notification, and train staff at least once a year.

A short checklist

1. BAA signed with the cloud provider and every other vendor touching PHI
2. PHI kept only in eligible services
3. MFA, least privilege and quarterly access reviews
4. Encryption at rest and in transit, on servers and on devices
5. Audit logging on, protected and retained
6. Backups tested by restoring them
7. Risk analysis, policies and training documented

None of these steps is complicated on its own. The work is in doing all of them consistently, and keeping the evidence that you have.