Healthcare Cloud Considerations
Reviewed by Fully Compliance editorial staff
Moving patient data to the cloud distributes your data across infrastructure you do not control, and your HIPAA compliance obligations expand rather than shrink. You remain the covered entity responsible for breaches even when the cloud vendor's negligence caused them. A strong Business Associate Agreement, verified encryption with controlled key management, documented shared responsibility, and ongoing vendor oversight are non-negotiable requirements for healthcare cloud deployments.
Your Compliance Obligations Expand When Data Moves to the Cloud
Moving patient data to the cloud promises operational efficiency, scalability, and reduced capital expense. It also distributes your data across infrastructure you don't control, operated by vendors you have limited visibility into, in geographic locations you don't know. Your compliance obligations don't shrink when data moves to the cloud — they expand. You remain responsible for ensuring that patient data is protected, that access is controlled, that HIPAA requirements are met. The cloud vendor is responsible for specific elements, but the overall accountability remains with your organization. Understanding where that boundary lies and how to verify that the vendor is actually meeting their obligations is essential.
Cloud vendors understand healthcare compliance requirements, but they also understand that most healthcare organizations don't deeply audit their compliance. The result is a spectrum of cloud vendors from those with robust healthcare practices to those with minimal security controls who simply claim to be HIPAA-compliant. Because you depend on the vendor's security, vendor selection and ongoing oversight matter more in healthcare cloud scenarios than in typical enterprise IT.
Covered Entity Obligations Don't Disappear
Moving to cloud doesn't eliminate your organization's compliance obligations under HIPAA. You remain the covered entity responsible for ensuring that patient data is protected. The cloud vendor becomes a business associate, subject to specific obligations outlined in a Business Associate Agreement. The division of responsibility is critical: your organization remains responsible for the overall security program, risk assessment, incident response, workforce access controls, and training. The cloud vendor is responsible for implementing the technical and administrative controls you've required in the BAA.
This shared responsibility model means that a breach caused by the cloud vendor's negligence is your responsibility to report. You're legally liable for the breach. You must notify affected patients. You must notify HHS. You can sue the vendor for damages, but you cannot escape the primary liability. HHS enforcement data shows that covered entities have been fined for breaches caused by business associate failures when the covered entity lacked adequate vendor oversight. This is why the BAA isn't a paperwork exercise — it's your contractual mechanism for requiring the vendor to implement appropriate controls and for holding them accountable if they fail.
Your risk assessment must include an assessment of cloud security. Where is patient data stored? What controls does the vendor implement around access, encryption, audit logging, backup, and incident response? What's the vendor's uptime and disaster recovery capability? The compliance program that moves to cloud must explicitly address cloud-specific risks: how do you verify that the vendor is actually encrypting data at rest, how do you detect if the vendor has been compromised, how do you respond if the vendor experiences a breach, what's your backup and recovery strategy if the vendor becomes unavailable, and what happens to patient data if the vendor goes out of business or cancels the service.
The BAA Is Your Primary Control Mechanism
The Business Associate Agreement is the legal contract that specifies the cloud vendor's obligations and your rights. A strong BAA should require encryption of data at rest and in transit, audit logging of access, regular security testing, incident response capabilities, backup and recovery, compliance with HIPAA security rule requirements, and assistance with breach notification if required.
The BAA should specify the vendor's responsibilities for different categories of controls. Technical controls like encryption and access logging are typically vendor-provided. Administrative controls like training and access reviews are shared — the vendor provides the capability but your organization maintains the responsibility. Physical controls are entirely vendor-provided since you don't control their data centers.
Subcontractors are a critical BAA consideration. If the cloud vendor uses other vendors to provide services — a backup vendor, a security monitoring vendor, a data analytics vendor — those subcontractors are subject to HIPAA's business associate rules. The BAA should require the cloud vendor to ensure that all subcontractors have appropriate agreements in place. You want visibility into which subcontractors are handling your data and what controls they have.
The BAA should specify data location. Where is your data physically stored? Can the vendor move your data to different locations without your consent? If data must remain within the United States for compliance reasons, the BAA should require that. Data sovereignty is often overlooked but it has legal implications. The BAA should also include audit rights — the right to audit the vendor's controls, request documentation of security practices, conduct penetration testing, and review audit reports. Vendors should be willing to provide SOC 2 reports or other third-party audit documentation demonstrating their security controls. Liability and indemnification provisions matter too: the vendor's liability if they're breached should be significant enough to incentivize the vendor to actually implement controls rather than treating security as optional.
Data Residency and Encryption Key Control
Patient data is subject to laws where it's located. If your patient data is stored in a cloud vendor's data center in another state, the laws of that state apply to the data. HIPAA doesn't specify data location requirements, but some states have their own healthcare privacy laws with location requirements. California's CPRA has specific requirements about data storage. New York's SHIELD Act has data security requirements. Some healthcare organizations have contractual requirements from customers or insurers about where data must be stored.
Jurisdictional considerations include understanding what legal process a government could use to compel the cloud vendor to disclose patient data. The CLOUD Act created a mechanism for U.S. law enforcement to compel cloud vendors to disclose data even if it's stored outside the United States.
Encryption is a critical control for cloud data, but the effectiveness depends entirely on who controls the encryption keys. If the cloud vendor controls the encryption keys, they can decrypt your data whenever they want. If you control the encryption keys, the vendor can encrypt and store your data but can't decrypt it without your keys. This is a massive difference in security posture.
Customer-managed keys, also called bring-your-own-key or BYOK, give you control over encryption keys. You manage the keys, the vendor uses them to encrypt and decrypt your data, but the vendor never has access to the unencrypted keys. This is more secure but also more operationally complex — if you lose the encryption key, your data is unrecoverable. Vendor-managed keys are easier operationally but shift control to the vendor. Most healthcare organizations use a hybrid approach: the cloud vendor encrypts data at rest using encryption keys stored in a key management system, and the healthcare organization controls access to the key management system and has visibility into which systems access the keys.
AES with 256-bit keys is the standard for healthcare. Key rotation should happen every 90 days to annually depending on your organization's policy. The cloud vendor should support automatic key rotation or provide clear processes for manual key rotation.
Shared Responsibility Requires Active Monitoring
Shared responsibility models vary by cloud service type. Infrastructure-as-a-service vendors provide the underlying infrastructure but you're responsible for patching operating systems, securing applications, and managing configuration. Platform-as-a-service vendors handle more of the infrastructure and you focus on application security. Software-as-a-service vendors handle the entire technology stack and you focus on user access and configuration.
For healthcare, SaaS solutions for EHRs, practice management, and billing are common. You're trusting the vendor to handle all the technical security. The vendor should provide documentation of their controls and should have third-party audits verifying those controls. SaaS vendors serving healthcare should have SOC 2 Type II reports covering their security controls. Access control within the cloud environment matters — you should understand how the cloud vendor restricts which of their employees can access your data. Ideally, no vendor employees have direct access to patient data without explicit authorization and logging.
The documented responsibility model should address access control, encryption, audit logging, incident response, backup and recovery, vulnerability management, and compliance monitoring. For each element, clarity about whether it's vendor-provided, shared, or your responsibility prevents gaps and reduces risk. Regular monitoring of the vendor's controls is your responsibility. You should request SOC 2 reports periodically, review audit logs showing vendor access to your data, conduct audits of the vendor's controls, and follow up on any findings from third-party assessments. Don't assume compliance based on the vendor's claims — verify it.
Incident Response and Backup in Cloud Environments
Despite all preventive controls, incidents happen. Your organization needs to know how to detect, respond to, and communicate about incidents affecting cloud-stored data. The BAA should specify that the vendor will notify you of any security incidents affecting your data within a specific timeframe — often 24 hours for potential breaches, immediately for confirmed breaches. The vendor should provide sufficient information for you to determine whether your data was actually compromised and what steps need to be taken.
The incident response process needs to account for your limited visibility into the cloud vendor's systems. You can't directly access their logs or investigate the incident yourself. You depend on the vendor's investigation and their willingness to provide you with details. The BAA should give you rights to conduct independent forensic investigations or to have a third-party forensic firm investigate on your behalf. Forensic preservation is critical — evidence needs to be preserved immediately so that it can be analyzed.
If patient data in the cloud is compromised, you must notify affected patients, notify HHS, and notify media depending on the scale. HHS requires this notification within 60 days of discovery for breaches affecting 500 or more individuals. Your organization needs documented processes for determining whether a breach occurred, what data was affected, and how many patients were affected.
Cloud backups need to be separate from the primary system so that a compromise of the primary system doesn't destroy the backups. Ideally, backups are in a geographically separate location. Your organization should test the recovery process — can you actually recover data from the cloud vendor's backups, and how long does recovery take? HIPAA requires maintaining records for at least six years after the last patient encounter, and cloud backup policies should align with those requirements. Test recoveries periodically to verify that backup and recovery actually work. The cloud vendor should provide information about backup frequency and recovery capability, with daily backups as the standard minimum.
Your organization's security program must explicitly address cloud-specific risks in documentation. Risk assessments should identify risks specific to cloud deployments. Incident response plans should address cloud-specific incidents. Workforce training should include cloud security practices. The compliance program that relies on cloud vendors needs to be comprehensive and vendor-independent — if you change vendors, your security program shouldn't collapse.
Frequently Asked Questions
Is my organization liable for a breach caused by our cloud vendor?
Yes. As the covered entity under HIPAA, you are responsible for reporting the breach, notifying affected patients, and notifying HHS regardless of whether the vendor's negligence caused the breach. You can pursue the vendor for damages through your BAA, but the primary regulatory liability rests with you.
Does HIPAA require that patient data stay in the United States?
HIPAA itself does not specify data location requirements. However, some state laws impose data residency requirements, and some organizational contracts or insurance policies require domestic storage. Your BAA should specify where data will be stored and prohibit the vendor from moving data without your consent.
Should we use customer-managed encryption keys or vendor-managed keys?
Customer-managed keys (BYOK) provide stronger security because the vendor cannot decrypt your data without your keys. However, they add operational complexity — losing the key means losing the data. Most healthcare organizations use a hybrid approach where the vendor manages encryption but the organization controls and monitors access to the key management system.
What documentation should we get from our cloud vendor?
Request their SOC 2 Type II report, their security policies and procedures, their incident response plan, their business continuity and disaster recovery plan, and documentation of their encryption practices and key management. Review these annually and follow up on any findings or gaps.
How do we verify that our cloud vendor is actually HIPAA-compliant?
Request and review their SOC 2 Type II audit report, which is an independent third-party assessment of their security controls. Review their BAA terms for specific security commitments. Ask for documentation of their HIPAA compliance program. Exercise your audit rights under the BAA periodically. A vendor's claim of HIPAA compliance without third-party verification is not reliable on its own.
What happens to our patient data if the cloud vendor goes out of business?
Your BAA should address this explicitly. It should require the vendor to provide you with a complete copy of your data in a usable format and to securely destroy their copies within a specified timeframe. Without these terms, you risk losing access to patient data or having it retained by an entity with no obligation to protect it.