Cloud adoption in healthcare has accelerated significantly, driven by the scalability demands of modern EHR platforms, the data requirements of clinical analytics and AI, and the disaster recovery benefits that cloud infrastructure provides. Alongside these benefits come security responsibilities that many healthcare organisations underestimate. Moving ePHI to the cloud does not transfer regulatory accountability — the covered entity remains responsible for protecting patient data regardless of where it is stored.
The Shared Responsibility Model
Every major cloud provider operates on a shared responsibility model. The cloud provider is responsible for security of the cloud — the physical infrastructure, hypervisor, network fabric, and managed service platform. The customer is responsible for security in the cloud — the data, applications, access controls, encryption configuration, and operating systems deployed on the platform.
For healthcare organisations, this means that choosing a HIPAA-eligible cloud service does not make the deployment HIPAA compliant. The organisation must correctly configure access controls, enable appropriate logging, manage encryption keys, and implement the security controls required by the Security Rule. Misconfiguration is the leading cause of cloud data breaches, and healthcare data stored in misconfigured cloud storage buckets has been exposed repeatedly in published breach incidents.
Business Associate Agreements with Cloud Providers
Before storing ePHI in any cloud service, the covered entity must have a signed Business Associate Agreement (BAA) with the cloud provider. All three major cloud providers — AWS, Microsoft Azure, and Google Cloud — will sign BAAs for their HIPAA-eligible services. Only specific services in each provider's portfolio are covered under the BAA; not every service offered by a cloud provider is HIPAA-eligible.
Healthcare organisations must identify which services they are using and verify that each is covered under their BAA. Services outside the BAA scope cannot be used to store or process ePHI. Cloud providers publish their HIPAA-eligible service lists, and these should be reviewed when adopting new services.
Sub-processors and third parties in the cloud supply chain also require BAAs — if a SaaS application deployed on a cloud platform sub-processes ePHI to additional services, those relationships must be assessed.
Encryption at Rest
All ePHI stored in cloud environments must be encrypted at rest. Major cloud providers offer managed encryption services that can be applied to storage buckets, databases, and virtual machine disks. The key question for healthcare organisations is who controls the encryption keys.
Provider-managed keys are convenient but mean that the cloud provider has technical access to keys and could potentially access encrypted data. For most healthcare workloads, this is acceptable given the contractual protections of a BAA.
Customer-managed keys (AWS KMS customer-managed keys, Azure Key Vault customer-managed keys) keep key management under the organisation's control. The cloud provider encrypts and decrypts data using keys that the customer controls, providing an additional layer of separation.
Customer-provided keys (also called bring your own key, or BYOK) allow organisations to supply keys from their own HSMs, keeping key material entirely outside cloud provider infrastructure. This is appropriate for the most sensitive workloads.
Key management procedures must be documented — including who has access to keys, how keys are rotated, and what happens to keys when a vendor relationship ends.
Encryption in Transit
All ePHI in transit between systems — between cloud services and end users, between cloud services internally, and between cloud and on-premise systems — must be encrypted. TLS 1.2 or higher is the current standard. Older versions of TLS and SSL should be disabled. Certificate management, including expiry monitoring and renewal processes, is an operational necessity that is often overlooked until a certificate expiry causes an outage or a degraded security state.
Cloud provider services generally enforce encryption in transit by default for managed services, but custom applications and integrations must be verified.
Access Controls and IAM
Cloud IAM is where misconfiguration most commonly leads to breach. The principle of least privilege — granting only the permissions required for a given role or workload — must be rigorously applied.
Key practices include:
- Never using root or global administrator accounts for routine operations. Root accounts should have hardware MFA enabled and be used only for account-level administrative tasks.
- Using role-based access control (RBAC) to assign permissions based on function rather than individual user.
- Applying IAM conditions to restrict access by IP address, time of day, or device compliance status where appropriate.
- Regularly auditing IAM configurations to identify overprivileged accounts, unused credentials, and legacy access grants.
- Disabling or rotating access keys that are no longer needed.
Service accounts and application credentials deserve particular attention — these are frequently overprivileged and less carefully managed than human user accounts.
Audit Logging and Monitoring
HIPAA requires audit controls on systems containing ePHI. In cloud environments, this means enabling and retaining cloud provider audit logs:
- AWS CloudTrail captures API calls across all AWS services, providing a record of who did what and when. CloudTrail logs should be enabled for all regions, stored in a dedicated logging account, and protected from modification or deletion.
- Azure Monitor and Azure Activity Log provide equivalent functionality for Azure environments.
- Google Cloud Audit Logs cover admin activity, data access, and system events in GCP.
Logs should be centralised in a SIEM for analysis. Alerting rules should flag suspicious patterns: access from unfamiliar geographies, large data exports, changes to security configurations, creation of new privileged accounts, and disabling of logging or security controls.
Log retention should be sufficient to support both HIPAA compliance and forensic investigation needs — typically a minimum of six years for HIPAA documentation, though security best practice may warrant longer retention for security-relevant logs.
Data Residency Considerations
For healthcare organisations operating in multiple countries, data residency requirements add complexity to cloud architecture decisions. The European Union's GDPR, the UK GDPR, and various national health data regulations impose requirements on where patient data can be stored and processed. Cloud providers offer region-specific deployments that enable data residency commitments, but these must be actively configured — data does not automatically stay in a specific region without explicit configuration.
Healthcare organisations should map their patient population to applicable data residency requirements and ensure that cloud architecture decisions are reviewed by legal counsel familiar with the relevant jurisdiction.
HIPAA-Eligible Services
AWS maintains a comprehensive list of HIPAA-eligible services that covers compute (EC2), storage (S3, EBS), databases (RDS, DynamoDB), analytics, and many AI/ML services. Azure's HIPAA compliance scope similarly covers core platform services plus Azure Health Data Services — a managed platform for FHIR, DICOM, and MedTech data.
Healthcare organisations should use the BAA and compliance scope documentation from their cloud provider as a starting point for architecture decisions, not an afterthought.
Breach Notification Obligations in Cloud Environments
A security incident in a cloud environment does not change the HIPAA breach notification clock. If a misconfigured storage bucket exposes ePHI, the 60-day notification clock begins when the covered entity discovers or should have discovered the exposure. The fact that the exposure occurred in a cloud service does not change the obligation.
Cloud provider incident notification — the provider notifying the customer of a security event within the provider's infrastructure — is governed by the BAA terms. Customers should understand their providers' incident notification commitments and ensure that notifications will reach appropriate security and compliance personnel promptly.
FZ Consulting LLP helps healthcare organisations design and audit cloud security architectures that meet HIPAA requirements and industry best practices. Contact our team to review your cloud security posture.