Healthcare organizations increasingly rely on cloud platforms for applications, storage, analytics, backups, and everyday operations. The question is no longer whether protected health information can be stored or processed in the cloud. It can. The real challenge is making sure the environment is designed and operated in a way that supports HIPAA requirements.
That distinction matters. A cloud provider may offer HIPAA-eligible services and sign a Business Associate Agreement (BAA), but that alone does not make a specific application or infrastructure setup compliant. Access controls, logging, data flows, backup procedures, security configurations, and ongoing risk management still need to be handled correctly.
This guide explains HIPAA compliance in cloud computing, the controls healthcare organizations should review, common mistakes to avoid, and what to consider when choosing a HIPAA-compliant cloud provider.
Why HIPAA Compliance Is a Must in the Cloud Era
HIPAA was introduced long before modern public cloud platforms became standard infrastructure. Its Security Rule, however, applies to electronic protected health information (ePHI) regardless of where that information is stored or processed.
The official HHS guidance on HIPAA and cloud computing confirms that covered entities and business associates can use cloud services for ePHI when applicable HIPAA requirements are met and the required agreements are in place.
In other words, using AWS, Microsoft Azure, Google Cloud, or another cloud platform is not a compliance issue by itself. The way the environment is configured and managed is what matters.
A real-world example comes from Health2Sync, a digital health company that relies on AWS infrastructure to operate healthcare services across multiple markets. According to the AWS Health2Sync case study, the company uses cloud infrastructure to scale its platform while addressing healthcare requirements, including HIPAA in the United States.
Health2Sync co-founder and CEO Ed Deng described the outcome:
“With AWS, we can deliver the scale, reliability, and compliance to help patients everywhere.”
AWS also reports that the project helped Health2Sync achieve faster deployments, lower latency, reduced infrastructure management time, and high platform availability.
AppRecode has worked with similar infrastructure requirements in digital health. Its Synapticure healthcare case study covers a US digital-health platform focused on ALS care. The project included scalable cloud infrastructure, Terraform-based Infrastructure as Code, Kubernetes, automated CI/CD with GitHub Actions and ArgoCD, and infrastructure monitoring.
The important point is simple: cloud infrastructure can support healthcare workloads effectively, but HIPAA cloud compliance depends on how that infrastructure is built, documented, secured, and maintained.
HIPAA and Cloud Storage: What's Allowed and What's Not
HIPAA and cloud storage are compatible.
Covered entities and business associates may use cloud services to store and process ePHI, provided they meet the applicable requirements of the HIPAA Rules.
One of the first things to clarify is the relationship with the cloud service provider.
If a provider creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate, it will generally be considered a business associate. In that situation, an appropriate BAA is required.
This can apply even when the cloud provider stores encrypted information without having access to the decryption key.
Another common misconception is that only private cloud infrastructure can be HIPAA compliant.
That is not the case.
Public, private, and hybrid cloud environments can all be used for healthcare workloads. The organization still needs to understand where ePHI is stored, how it moves between systems, who can access it, which vendors are involved, and which safeguards protect it.
Encryption requires similar nuance.
Under the HIPAA Security Rule currently in effect, encryption is an addressable implementation specification. Organizations must evaluate whether encryption is a reasonable and appropriate safeguard within their environment.
That does not mean encryption can simply be ignored. If an organization chooses not to implement an addressable specification as written, the decision needs to be justified and documented, with an appropriate alternative safeguard implemented where necessary.
In practice, modern healthcare cloud environments normally use strong encryption both at rest and in transit. The important distinction is that HIPAA itself does not mandate one universal cipher, cloud architecture, or protocol version for every organization.
Cloud Computing and HIPAA Compliance: Key Requirements
There is no single “HIPAA mode” that makes cloud infrastructure compliant.
Cloud computing and HIPAA compliance come together through a combination of administrative, technical, and operational safeguards.
Risk Analysis
Risk analysis is one of the foundations of HIPAA security.
Organizations need to identify potential risks and vulnerabilities affecting the confidentiality, integrity, and availability of ePHI.
For practical implementation, the NIST HIPAA Security Rule Cybersecurity Resource Guide provides a structured framework for understanding and implementing Security Rule requirements.
In a cloud environment, a meaningful risk analysis may need to cover:
- cloud accounts and subscriptions;
- applications and APIs;
- databases and object storage;
- identity and access management;
- backup systems;
- CI/CD pipelines;
- third-party integrations;
- monitoring tools;
- service accounts;
- user devices;
- data flows between systems.
Risk analysis should also reflect how the environment actually operates today.
A document created during the initial migration is not enough if the architecture has since changed significantly.
Risk Management
Identifying a risk is only the first step.
The organization then needs to determine which safeguards are reasonable and appropriate and decide how identified risks will be reduced.
A cloud migration can introduce new IAM roles, storage policies, APIs, deployment pipelines, integrations, and administrative accounts. Each of these creates configuration decisions that can affect ePHI.
Risk management is therefore an ongoing process rather than a one-time compliance task.
Business Associate Agreements
A BAA establishes how a business associate may use and disclose ePHI and defines responsibilities for protecting it.
When a cloud provider handles ePHI on behalf of a covered entity or another business associate, an appropriate BAA will generally be required.
But signing a BAA should not be confused with making the environment compliant.
A BAA does not automatically secure a Kubernetes cluster, database, storage bucket, application, user account, or API.
Those controls still need to be designed and managed correctly.
Access Controls and Authentication
Access to systems containing ePHI should be limited to authorized users and aligned with their responsibilities.
That normally includes:
- unique user identities;
- role-based permissions;
- least-privilege access;
- controlled privileged accounts;
- regular access reviews;
- secure authentication.
Multi-factor authentication is widely used because it significantly improves account security.
However, it is better to describe MFA as a strong security control rather than claim that the currently effective HIPAA Security Rule imposes the same standalone MFA requirement on every system.
The appropriate authentication approach should reflect the sensitivity of the data, the users accessing it, and the risks identified during assessment.
Audit Controls
Organizations need mechanisms for recording and examining activity in information systems that contain or use ePHI.
In a cloud environment, useful audit data may include:
- user sign-ins;
- privileged actions;
- configuration changes;
- changes to IAM permissions;
- application events;
- database activity;
- infrastructure changes;
- security alerts.
Simply enabling logs is not enough.
Organizations also need to determine what should be monitored, how long relevant logs should be retained, and what happens when suspicious activity is detected.
Transmission Security
ePHI transmitted over electronic networks needs protection against unauthorized access.
Encryption is commonly used for this purpose.
The implementation should be based on current security practices and the organization’s risk assessment rather than an arbitrary list of supposedly “HIPAA-approved” protocols.
Backup and Contingency Planning
Availability is another important part of healthcare security.
Organizations need processes for data backup, disaster recovery, emergency operations, and restoration of systems that contain ePHI.
A backup strategy should answer practical questions:
- Which systems are critical?
- How much data loss is acceptable?
- How quickly should services be restored?
- Where are backups stored?
- Who can access them?
- How often is restoration tested?
Organizations that do not want to manage the full recovery layer internally may use cloud backup and disaster recovery services to support automated backups, recovery procedures, and infrastructure resilience.
The healthcare organization still needs to ensure that the recovery strategy reflects its own regulatory and operational responsibilities.
Common Mistakes to Avoid When Moving HIPAA Data to the Cloud
Many HIPAA cloud security problems are caused by ordinary operational mistakes rather than sophisticated attacks.
Assuming the Cloud Provider Handles Compliance
This is one of the most common misconceptions.
Cloud providers secure their underlying platforms, but customers still control significant parts of the environment.
Depending on the service model, that may include:
- IAM permissions;
- application security;
- storage configuration;
- databases;
- network rules;
- credentials;
- integrations;
- operating systems;
- encryption settings;
- logging.
A BAA does not transfer every HIPAA responsibility to the cloud provider.
Treating Encryption as the Entire Security Strategy
Encryption is important, but it cannot compensate for poorly managed access.
An encrypted database can still be exposed if an attacker obtains valid administrator credentials.
Encryption also does not solve problems such as:
- excessive IAM permissions;
- compromised accounts;
- insecure APIs;
- missing logs;
- weak incident response;
- untested backups;
- configuration errors.
It should be part of a broader security architecture.
Granting Excessive Access
Permissions tend to accumulate over time.
An engineer may receive temporary production access during a migration. A vendor may receive broad permissions during troubleshooting. A project team may retain access months after the work has ended.
Without regular reviews, “temporary” permissions can quietly become permanent.
Least privilege only works when access is periodically reviewed and removed when no longer necessary.
Ignoring Shadow IT
The primary cloud platform may be carefully managed while sensitive data leaves it through another tool.
Employees may introduce:
- file-sharing services;
- AI tools;
- browser extensions;
- messaging platforms;
- analytics tools;
- SaaS applications.
If PHI is transferred to a system that has not gone through appropriate review, the organization can create a compliance and security problem outside its main infrastructure.
Confusing Good Security Practice With Exact HIPAA Requirements
Some controls are simply good security engineering.
Vulnerability scanning, penetration testing, MFA, SIEM platforms, automated security checks, and continuous monitoring can all strengthen healthcare cloud security.
Problems arise when they are described as though HIPAA prescribes exactly the same technology, frequency, or implementation for every organization.
HIPAA takes a risk-based approach. Controls should be connected to real systems and documented risks.
Neglecting Recovery Testing
A backup is useful only if it can be restored.
Organizations should periodically confirm that recovery procedures actually work and that teams understand what to do during an outage or security incident.
This is especially important for healthcare platforms where service availability may directly affect patient-facing operations.
Checklist: Is Your Cloud HIPAA-Ready?
The following checklist can help teams review HIPAA compliance for cloud services. It is not a replacement for formal risk analysis.
- Identify where ePHI is stored, processed, and transmitted.
- Understand which cloud services handle ePHI.
- Confirm that required BAAs are in place.
- Maintain a current risk analysis.
- Restrict access according to business need.
- Review privileged permissions regularly.
- Use authentication controls appropriate to the risk.
- Evaluate encryption for data at rest and in transit.
- Document security decisions.
- Enable audit logging for systems that contain or use ePHI.
- Review important security events.
- Maintain incident-response procedures.
- Define backup and disaster-recovery processes.
- Test restoration procedures.
- Review third-party services and integrations.
- Train workforce members on security responsibilities.
- Reassess controls when infrastructure changes.
- Review applicable state privacy and healthcare requirements.
HIPAA should be treated as a baseline for protecting health information rather than the maximum level of security an organization may ever need.
Choosing a HIPAA-Compliant Cloud Provider
A HIPAA-compliant cloud provider is not simply a company that mentions HIPAA on its website.
The evaluation should start with the BAA.
Confirm whether the provider will enter into an appropriate agreement for the services that will create, receive, maintain, or transmit ePHI.
Then examine how those services fit the architecture.
Service Eligibility
Major cloud providers offer hundreds of products.
Teams should not assume that every service falls under the same compliance program.
Before placing ePHI into a new service, confirm that the service is appropriate for the workload and covered by the necessary contractual arrangements.
Identity and Access Management
Review how the provider handles:
- roles;
- privileged accounts;
- temporary access;
- service identities;
- federation;
- authentication;
- permission boundaries.
Powerful IAM features do not help if the environment is configured too broadly.
Encryption and Key Management
Do not stop at “encryption enabled.”
Understand:
- who manages encryption keys;
- where keys are stored;
- who can access them;
- how they are rotated;
- how encryption is applied to backups and replicas.
Logging and Monitoring
Make sure the platform provides sufficient information for security investigations and routine monitoring.
Cloud logs are only valuable when they are collected, retained, and reviewed in a useful way.
Backup and Resilience
Understand:
- how data is backed up;
- where backups are stored;
- how restoration works;
- what happens if a service or region becomes unavailable;
- which responsibilities belong to the provider;
- which responsibilities remain with your organization.
Incident Response
Review the provider’s security notification procedures and understand what information will be available if an incident affects your environment.
These details should also align with internal response procedures.
AWS, Microsoft Azure, and Google Cloud can all support healthcare workloads. The challenge is building and maintaining the environment around them correctly.
Organizations that do not want their internal product team to manage the entire operational layer may use managed cloud services for ongoing cloud operations and infrastructure management.
Teams that have already standardized on a specific platform may instead use AWS managed cloud services or Azure managed cloud services for platform-specific engineering and maintenance.
Experience with healthcare environments is also relevant.
The Synapticure project gave AppRecode practical experience with cloud infrastructure for a digital-health platform, including Kubernetes, Infrastructure as Code, automated delivery, and monitoring.
There is also independent client feedback.
In a verified Clutch review of AppRecode, a digital-health company reported improved system stability, more predictable releases, better visibility into cloud costs, and lower operational overhead after an infrastructure modernization engagement.
The reviewer summarized AppRecode’s approach as:
“Their structured, business-oriented mindset stood out most.”
For a healthcare organization evaluating an infrastructure partner, this type of independently verifiable project feedback is considerably more useful than anonymous success stories or generic claims.
The Role of Security in HIPAA and Cloud Computing
HIPAA and cloud computing have one important characteristic in common: neither can be treated as a one-time project.
Cloud environments change continuously.
Teams:
- deploy new services;
- update applications;
- add vendors;
- modify IAM policies;
- change infrastructure through code;
- introduce integrations;
- create new data flows.
As the environment changes, the risk profile changes with it.
A mature healthcare cloud security program will usually include some combination of:
- identity and access management;
- centralized logging;
- infrastructure monitoring;
- vulnerability management;
- configuration controls;
- encryption and key management;
- backup and recovery;
- incident response;
- Infrastructure as Code;
- controlled CI/CD;
- recurring access reviews;
- periodic risk assessment.
Organizations do not necessarily need to operate every security function internally.
Where internal resources are limited, managed cloud security services can provide additional engineering, monitoring, and operational support.
That does not transfer regulatory responsibility away from the healthcare organization.
It simply means that specialized teams can help implement and maintain the technical controls required around the cloud environment.
The goal is not to collect security tools or compliance badges.
The goal is to keep ePHI protected as systems, users, vendors, and infrastructure change.
Conclusion
HIPAA compliance in cloud computing is achievable, and cloud infrastructure is already widely used throughout healthcare.
The mistake is assuming that choosing a major provider, signing a BAA, or moving sensitive information into a private cloud automatically creates a compliant environment.
It does not.
A strong HIPAA cloud compliance program starts with understanding where ePHI is located, how it moves, who can access it, and which risks affect it.
From there, organizations can build appropriate controls around access, authentication, logging, encryption, backup, recovery, incident response, and vendor management.
Cloud infrastructure can make many of these controls easier to standardize and automate.
It does not remove the need to manage them.
Frequently Asked Questions
Is AWS HIPAA compliant by default?
No.
AWS offers services that can be used for HIPAA-regulated workloads and supports BAAs for eligible customers and services.
However, an application does not automatically become HIPAA compliant simply because it runs on AWS.
The customer still needs to manage areas such as access control, application security, logging, backup, encryption decisions, configurations, and risk management.
Does HIPAA require data encryption in the cloud?
Encryption is an addressable implementation specification under the HIPAA Security Rule currently in effect.
Organizations need to evaluate whether encryption is a reasonable and appropriate safeguard based on their risk analysis.
If an addressable specification is not implemented as written, the decision should be documented and an appropriate alternative safeguard implemented where necessary.
In modern healthcare cloud environments, encryption at rest and in transit is generally treated as an important security baseline even though HIPAA does not prescribe one universal encryption technology for every organization.
How do you verify whether a cloud setup meets HIPAA requirements?
Start by identifying where ePHI is stored, processed, and transmitted.
Then review:
- vendors handling the data;
- BAAs;
- user access;
- authentication;
- logging;
- encryption;
- security monitoring;
- incident-response procedures;
- backup and recovery;
- third-party integrations.
The results should be tied back to the organization’s risk analysis.
No individual cloud certification, automated scan, or provider badge proves that the entire environment is HIPAA compliant.
Can small healthcare startups use HIPAA-compliant cloud services?
Yes.
HIPAA does not restrict cloud infrastructure to hospitals or large healthcare organizations.
A healthcare startup can use cloud services for ePHI as long as it meets the applicable requirements.
Smaller teams may rely more heavily on managed infrastructure, security, or monitoring services, but they still need to understand their own responsibilities.
What is the difference between HIPAA compliance and GDPR in the cloud?
HIPAA applies specifically to protected health information handled by covered entities and business associates within the US healthcare system.
GDPR applies more broadly to personal data within its territorial scope and is not limited to healthcare.
An international healthcare organization may therefore need to address both frameworks.
Its cloud architecture should be based on the actual data processed, applicable jurisdictions, contractual responsibilities, and regulatory requirements rather than treating HIPAA compliance as a substitute for broader privacy obligations.
