HIPAA Compliance in Cloud Computing: What You Need to Know

HIPAA compliance in cloud computing means protecting electronic protected health information (ePHI) to the standard of the HIPAA Privacy, Security, and Breach Notification Rules while that data is stored or processed by a cloud provider. HIPAA does not ban the public cloud. It requires a Business Associate Agreement (BAA) with the provider, a risk analysis that covers your cloud environment, and safeguards that you configure and can prove. The provider secures the platform. Everything you build on it, from IAM roles to storage buckets and logs, stays your responsibility.

This guide is written for CTOs, security leads, and DevOps engineers at healthcare and health-tech companies. It explains what the rules actually require, how responsibility is split with AWS, Azure, or Google Cloud, which controls map to which Security Rule safeguards, and where cloud HIPAA programs usually fail.

• The cloud is allowed. The HHS guidance on HIPAA and cloud computing confirms that covered entities and business associates may use cloud services for ePHI, provided a BAA is in place and the HIPAA Rules are followed.
• A cloud provider that stores ePHI is a business associate, even if it only holds encrypted data and has no key.
• No provider is “HIPAA compliant” out of the box. AWS, Microsoft Azure, and Google Cloud sign BAAs and publish lists of HIPAA-eligible services. Compliance depends on how you configure and operate  them.
• There is no official HIPAA certification for clouds or vendors. Third-party attestations help with due diligence, but they don’t replace your own risk analysis.
• Encryption is still “addressable” today, but in practice it is expected. A 2025 proposal would make encryption and MFA mandatory.
• Compliance is continuous. Infrastructure changes every week, so the risk analysis, access reviews, and evidence have to keep up.

Yes. HIPAA compliance in the cloud is possible and common. HIPAA was written in 1996, long before public cloud became standard infrastructure, but the Security Rule is technology-neutral. It applies to ePHI wherever it lives: in your own data center, in a SaaS tool, or in an AWS account.

HHS answers the question directly. A covered entity or business associate may use a cloud service to store or process ePHI if it signs a HIPAA-compliant BAA with the cloud service provider (CSP) and otherwise complies with the HIPAA Rules. The type of cloud does not matter: public, private, and hybrid deployments are all acceptable, as long as the risk analysis and BAA reflect the setup. In other words, HIPAA cloud computing is a question of controls and contracts, not of where the servers are.

Large health-tech platforms already run this way. The AWS case study on Health2Sync, a chronic disease management company, describes a platform on Amazon EKS built to meet HIPAA in the US, with 40% faster deployments and 50% less management time after the move.

HIPAA applies to two groups:

• Covered entities: health plans, health care clearinghouses, and health care providers that conduct standard transactions electronically.
• Business associates: vendors that create, receive, maintain, or transmit PHI on behalf of a covered entity, and their subcontractors.

A health-tech startup that builds software for clinics is usually a business associate. When that startup hosts ePHI on AWS, AWS becomes its subcontractor and also a business associate.

Three points from the HHS guidance are often misunderstood:

1. “No-view” providers are still business associates. A CSP that stores only encrypted ePHI and lacks the decryption key is still a business associate and needs a BAA.
2. The “conduit” exception is narrow. It covers services that only transmit data, such as an internet service provider. A CSP that stores ePHI, even temporarily beyond transmission, does not qualify.
3. Data can be stored outside the US. HIPAA does not prohibit offshore storage, but the risk analysis must account for it, and other laws or contracts may restrict it.

Every major cloud works on shared responsibility. The provider secures the physical facilities, hardware, and the services it runs. You secure what you put on top. How much is yours depends on the service model.

The pattern is clear: identity, data, logging, and the risk analysis stay with you in every model. That is also where most cloud HIPAA violations happen. A BAA makes the provider liable for its side, not for a bucket you made public.

A BAA sets out how the business associate may use and disclose PHI and obliges it to safeguard ePHI, report security incidents and breaches, and pass the same terms down to its subcontractors. HHS publishes sample BAA provisions that show what the contract must include.

With hyperscalers you usually don’t negotiate the BAA. You accept the provider’s standard addendum:

Two practical rules follow from this:

• ePHI may only go into covered services. On AWS, for example, you can use any service in an account designated for HIPAA, but ePHI may only be processed, stored, or transmitted by the services listed as HIPAA-eligible. A new managed AI or analytics service is not automatically on the list.
• The SLA matters too. HHS notes that service level agreements should address availability, backup and recovery, return of data at the end of the contract, and use and retention limits. A CSP cannot hold ePHI hostage, for example by blocking access during a billing dispute.

No. HHS does not certify cloud providers, software, or consultants as HIPAA compliant. Its FAQ on certifying compliance states that HHS does not endorse or recognize private “certifications” and that they do not relieve an organization of its HIPAA obligations. When a vendor says it is HIPAA certified, it usually means it passed a third-party assessment or that it will sign a BAA.

Independent attestations such as SOC 2 Type II, ISO/IEC 27001, and HITRUST are still useful. They show that the provider’s own controls were tested. They do not cover your account, your configuration, or your applications, which is why HHS still expects your own risk analysis.

Three rules shape cloud architecture:

• The Privacy Rule governs who may use and disclose PHI and for what purpose. In the cloud it shows up as the “minimum necessary” principle: each role should reach only the data it needs.
• The Security Rule requires administrative, physical, and technical safeguards for ePHI. In the cloud, physical safeguards sit mostly with the provider, while administrative and technical safeguards stay with you.
• The Breach Notification Rule requires notice to affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people must also be reported to HHS and, in many cases, to the media. Business associates must notify the covered entity.

The Breach Notification Rule has a direct technical consequence. HHS guidance on unsecured PHI explains that ePHI encrypted in line with NIST standards is not “unsecured,” so losing it is generally not a reportable breach, provided the keys were not compromised. That is why strong encryption with well-managed keys is one of the most valuable controls in a cloud HIPAA program.

HIPAA cloud security is built on the technical safeguards in 45 CFR §164.312, which translate into concrete cloud settings. The table below shows typical native controls on the three major platforms. Your exact choice depends on your architecture and risk analysis.

The administrative safeguards in §164.308 matter just as much. The most important one is the risk analysis, and it is the first document OCR asks for. Since 2024, OCR has run a dedicated Risk Analysis Initiative, and its resolution agreements repeatedly cite a missing or incomplete risk analysis, including in ransomware cases.

For implementation detail, NIST SP 800-66 Revision 2 is the standard companion to the Security Rule. It maps each standard to practical activities and NIST Cybersecurity Framework controls.

HIPAA compliant cloud computing comes down to a set of controls that you configure, document, and keep current. The same requirements apply whether you are building new HIPAA compliant cloud infrastructure or moving an existing system.

The risk analysis must identify where ePHI is created, stored, processed, and sent, and what could threaten its confidentiality, integrity, and availability. In the cloud that scope is wider than most teams expect. It should include accounts and subscriptions, databases and object storage, APIs, CI/CD pipelines, monitoring and logging tools, backups, third-party integrations, and service accounts.

A document written during the initial migration goes stale quickly. Update it when you add a region, a new managed service, a vendor, or a new data flow.

Finding a risk is the first step. The organization then decides which safeguards are reasonable and appropriate and records why. This matters most for “addressable” specifications: if you choose an alternative to the stated control, the reasoning and the alternative must be written down.

Give every person and workload a unique identity, avoid shared admin accounts, and scope IAM policies to what each role needs. Permissions tend to grow over time. An engineer gets temporary production access during a migration, a vendor gets broad rights for troubleshooting, and nobody removes them afterwards. Quarterly access reviews and short-lived credentials keep this under control.

The current Security Rule requires person or entity authentication but does not name MFA. In practice, MFA on every account that can reach ePHI is the baseline auditors expect. It is also what was missing in the Change Healthcare attack, which HHS records as affecting about 192.7 million individuals, the largest health data breach reported to date.

Encrypt ePHI at rest in every store that can hold it: object storage, block volumes, managed databases, snapshots, and backups. Enforce TLS for data in transit, including traffic between internal services. Use the provider’s key management service and decide who manages keys, who can use them, how they are rotated, and how they apply to replicas and backups.

Turn on control-plane logs (CloudTrail, Azure Activity Log, Cloud Audit Logs) and data-access logs for stores with ePHI. Send them to a separate, locked-down account or project so an attacker cannot delete them. Logging only counts if someone reviews it, so set alerts for unusual access, permission changes, and disabled logging. Our guide to monitoring applications in cloud environments covers the monitoring side in more depth.

The Security Rule requires a contingency plan with data backup, disaster recovery, and emergency mode operations. Define recovery time and recovery point objectives for systems with ePHI, keep immutable copies, and test restores on a schedule. Teams that don’t want to run this layer themselves often use cloud backup and disaster recovery services with documented restore tests.

Every SaaS tool, AI service, or analytics platform that touches ePHI needs its own review and its own BAA. Shadow IT is a common source of violations: PHI copied into a spreadsheet tool, a messaging app, or an AI assistant that never went through review.

HIPAA has no list of approved storage products, so storing PHI in the cloud is about how you configure the service. Cloud storage that holds ePHI must meet the same Security Rule safeguards as any other system. For object storage such as Amazon S3, Azure Blob Storage, or Google Cloud Storage, that usually means:

• the service is on the provider’s HIPAA-eligible list and covered by your BAA;
• public access is blocked at the account level, not only per bucket;
• encryption at rest is on by default, with customer-managed keys where your risk analysis calls for them;
• versioning and object lock protect against deletion and ransomware;
• access logging records who read or changed which objects;
• lifecycle rules delete data you no longer need to keep;
• replicas and backups get the same encryption and access rules as the primary copy.

Guardrails like these are easier to keep when they are defined as code. A minimal Terraform example for an S3 bucket with ePHI:

resource "aws_s3_bucket" "phi" {
  bucket              = "example-phi-records"
  object_lock_enabled = true
}

resource "aws_s3_bucket_public_access_block" "phi" {
  bucket                  = aws_s3_bucket.phi.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "phi" {
  bucket = aws_s3_bucket.phi.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.phi.arn
    }
  }
}

resource "aws_s3_bucket_versioning" "phi" {
  bucket = aws_s3_bucket.phi.id

  versioning_configuration {
    status = "Enabled"
  }
}

To check an account against these rules continuously, AWS offers the Operational Best Practices for HIPAA Security conformance pack for AWS Config. Azure Policy and Google Cloud’s Security Command Center provide similar built-in checks. These tools report configuration drift. They don’t decide whether your environment is compliant.

Most new health-tech platforms run on Kubernetes, and containers add places where ePHI can hide. Data may start in a pod, land on a persistent volume, get copied into a log line, and then be shipped to a third-party log platform.

In Kubernetes environments, a HIPAA program should cover:

• RBAC and namespaces: separate workloads that handle ePHI and limit who can exec into pods or read secrets, using Kubernetes RBAC.
• Secrets: keep credentials in a secrets manager (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) instead of plain Kubernetes Secrets in Git.
• Audit logs: enable Kubernetes audit logging or the managed equivalent in EKS, AKS, or GKE.
• Image scanning and admission policies: block images with critical vulnerabilities and containers that run as root.
• Network policies: restrict which services can talk to the pods that handle ePHI, and encrypt east-west traffic.
• PHI in logs: filter or mask identifiers before logs leave the cluster, and check that your log vendor is covered by a BAA.

Pipelines need the same attention, because a CI/CD system with production credentials can reach ePHI. Our CI/CD pipeline audit checklist explains how to review them for security and compliance gaps.

Assuming the provider handles compliance. A BAA covers the provider’s side. It does not configure your IAM, storage, databases, network rules, or logs.

Treating encryption as the whole strategy. An encrypted database is still exposed if an attacker gets valid administrator credentials. Encryption does not fix excessive permissions, insecure APIs, missing logs, or untested backups.

Using services outside the BAA. A new managed service, an AI API, or an observability tool can receive ePHI before anyone checks whether it is covered.

Copying production data to dev and test. Clones of production databases in non-production accounts are a frequent source of unprotected ePHI. Use synthetic or de-identified data instead.

Letting the risk analysis go stale. OCR enforcement shows that an outdated or partial risk analysis is the most common finding after a breach.

Never testing restores. A backup that has not been restored is an assumption, not a control. This matters most for patient-facing systems, where downtime affects care.

On January 6, 2025, HHS published a proposed rule to strengthen the HIPAA Security Rule. Among other changes, it would:

• remove the distinction between “required” and “addressable” specifications;
• make encryption of ePHI at rest and in transit mandatory, with limited exceptions;
• require MFA for access to systems with ePHI;
• require a written technology asset inventory and a network map;
• require vulnerability scanning at least every six months and penetration testing at least once a year;
• require the ability to restore critical systems within 72 hours.

As of November 2026, this is still a proposal, and the current Security Rule remains the one being enforced. Most of the proposed controls are already standard practice in well-run cloud environments, so building them in now is cheaper than retrofitting them later.

Use this checklist to review an existing environment or plan a migration. It does not replace a formal risk analysis.

1. Map where ePHI is created, stored, processed, and transmitted, including dev, test, analytics, and backups.
2. Confirm a BAA is in place with every cloud provider and vendor that touches ePHI.
3. Check that every service holding ePHI is on the provider’s HIPAA-eligible list.
4. Complete or update the Security Rule risk analysis and record decisions on addressable specifications.
5. Enforce unique identities, least privilege, and MFA for every account that can reach ePHI.
6. Encrypt ePHI at rest and in transit and document key ownership and rotation.
7. Enable audit logs, store them in a separate protected account, and review alerts.
8. Block public access to storage and restrict network paths to ePHI systems.
9. Define backup, disaster recovery, and RTO/RPO targets, and test restores.
10. Write and rehearse an incident response plan that meets the 60-day breach notification deadline.
11. Train staff on PHI handling and review shadow IT and AI tools.
12. Reassess controls whenever infrastructure, vendors, or data flows change.

If you want an outside view of where your environment stands, a DevOps health check gives you a prioritized list of infrastructure and security gaps before an auditor or an incident finds them.

Companies looking for HIPAA compliance cloud engineers usually need two skills in one team: knowing what the Security Rule expects and running production infrastructure that meets it every day.

AppRecode builds and runs production infrastructure for companies whose systems can’t go down, with healthcare among its core industries. Since 2019 the team has delivered more than 80 projects, mostly on AWS, with certified AWS, Azure, Google Cloud, Kubernetes, and Terraform engineers.

From our practice: Synapticure. For Synapticure, a US digital health company focused on ALS care, we automated the patient flow and back-office data processing and built cloud infrastructure fully covered by Terraform, microservices on Kubernetes, CI/CD with GitHub Actions and ArgoCD, and monitoring of application performance and infrastructure health. The result was faster, smaller releases with change approvals tied to risk, lower incident time thanks to SLO alerts and tested rollbacks, and audit-ready pipelines with environment parity for PHI workloads. Infrastructure as Code makes every change reviewable and repeatable, which is exactly the kind of evidence a HIPAA risk analysis and audit need.

“Ship small, prove every change, and keep patient data guarded by default. That is how health tech stays fast without breaking trust,” says Volodymyr Shynkar, CEO and co-founder of AppRecode.

A UK digital health company that worked with us described the project in a verified review on Clutch, where AppRecode holds a 5.0 rating. We assessed the client’s infrastructure and DevOps processes, built a roadmap for improvements, optimized cloud resource usage, and set up a monitoring stack for proactive incident detection. The client reported better system stability and lower operational overhead, and summed up the work this way: “Their structured, business-oriented mindset stood out most.”

We help healthcare teams in three ways:

• designing and operating HIPAA-ready AWS environments through AWS managed cloud services, with the same approach available on Azure;
• adding security controls, monitoring, and incident response through managed cloud security services;
• building security checks into delivery pipelines with DevSecOps services.

The legal responsibility for HIPAA stays with your organization. Our job is to make the technical side of it reliable, documented, and easy to prove.

No. AWS is HIPAA-eligible, not HIPAA compliant by default. It signs a BAA through AWS Artifact and publishes a list of HIPAA-eligible services you may use for ePHI.

Whether your environment complies depends on what you build. Access control, encryption settings, logging, backups, and the risk analysis remain your responsibility. The same applies to Azure, Google Cloud, and IBM Cloud.

No. HHS does not certify cloud providers or vendors, and there is no official “HIPAA certified” status.

Providers often hold SOC 2, ISO/IEC 27001, or HITRUST attestations. These are useful in vendor due diligence, but they cover the provider’s controls, not your configuration.

Under the current Security Rule, encryption is an addressable specification. You must implement it when it is reasonable and appropriate, or document why not and use an equivalent alternative.

In the cloud, encryption at rest and in transit is almost always reasonable, and encrypted ePHI generally falls under the breach notification safe harbor. The 2025 proposed rule would make encryption mandatory.

Yes. HHS states that a cloud provider that stores ePHI is a business associate even if it holds only encrypted data and has no decryption key.

The “conduit” exception applies only to services that transmit data without storing it, such as internet service providers.

HIPAA does not prohibit it. HHS says covered entities and business associates may use CSPs that store ePHI abroad.

The risk analysis must account for the location, and contracts, state laws, or customer agreements may still require US-only storage. Many US healthcare organizations choose US regions to keep things simple.

HIPAA applies to PHI handled by US covered entities and their business associates. GDPR applies to the personal data of people in the EU, in every industry, and treats health data as a special category.

A health-tech company serving patients in the US and Europe may need to meet both. The cloud architecture should follow the data, the jurisdictions involved, and the contracts, not assume that HIPAA compliance covers GDPR.

HIPAA compliance in cloud computing is achievable, and most of the healthcare industry already runs ePHI in the cloud. HIPAA in the cloud works when security is treated as an ongoing program. The mistake is to treat a BAA, a large provider, or a private cloud as the finish line.

A working program starts with knowing where ePHI lives and who can reach it. From there you build and document the controls the Security Rule expects: access, authentication, encryption, logging, backup, incident response, and vendor management. Cloud tooling and Infrastructure as Code make these controls easier to standardize and prove, and they still need to be maintained as your environment changes.

Need a second pair of eyes on your healthcare cloud? AppRecode engineers can review your AWS or Azure environment against the controls in this guide and give you a prioritized list of fixes. Get a free consultation. We reply within one business day.