HIPAA Compliant Cloud Storage: Choosing the Right Provider and Protecting Patient Data

Cloud storage now holds a growing amount of patient data, including medical records, lab results, billing information, and application data. But moving electronic protected health information (ePHI) to the cloud does not automatically satisfy cloud based storage HIPAA compliance requirements.

Getting a signed Business Associate Agreement (BAA) and enabling encryption doesn’t make your HIPAA compliant cloud storage environment secure.

Healthcare has now been the costliest industry for data breaches for thirteen years running, averaging $6.64 million per incident in 2026; in healthcare specifically, 59% of breaches were malicious or criminal attacks while 26% came down to IT failures. (Source)

Weak access controls, shared credentials, exposed backups, and ePHI in test environments can still put patient data at risk, no matter what a vendor’s compliance page says.

This guide breaks down what actually makes cloud storage HIPAA compliant, how storage differs from backup, what to vet in a provider beyond the BAA, and how to protect ePHI at every stage, not just when it’s at rest.

Cloud based storage HIPAA compliance involves more than encryption or picking a healthcare-focused vendor. Both you and the vendor share responsibility for protecting ePHI.

And if the cloud provider handles ePHI on your behalf, you need a signed BAA (Business Associate Agreement) in place with that vendor.

Here’s how that responsibility actually breaks down.

Your cloud provider is responsible for the physical infrastructure, including its data centers, hardware, and underlying network. Your organization is responsible for how you use and configure the cloud environment.

That can include:

• Bucket and storage permissions
• User access and IAM roles
• Multi-factor authentication (MFA)
• Encryption settings
• Data retention rules
• Devices that download or sync ePHI

A BAA does not automatically make your HIPAA compliant cloud storage environment secure.

For example, a cloud service may allow you to make a storage bucket public. If you configure it incorrectly and expose ePHI, the BAA will not prevent that mistake.

ePHI also rarely stays in one place. Copies spread into backups, logs, test environments, and connected tools, which is covered in detail later in this guide.

If a cloud provider stores or processes ePHI for you, make sure that provider has a BAA with your organization. More importantly, check that the specific cloud services you plan to use are covered by the BAA.

A BAA sets out how the provider must handle and protect ePHI. It typically covers areas such as:

• How ePHI can be used and disclosed
• Security requirements
• Breach and incident reporting
• Subcontractor responsibilities

But signing a BAA does not make your cloud environment automatically HIPAA-compliant.

It does not prevent problems such as:

• Misconfigured storage
• Excessive user permissions
• Weak passwords
• Missing MFA
• Poor encryption settings

Think of the BAA as a contract between you and the provider, not as proof that your HIPAA compliant cloud storage setup is secure.

Your organization still needs to properly configure and protect the environment. The BAA also does not tell you who controls the encryption keys. Cloud based storage HIPAA compliance therefore requires a review of both contractual protections and technical configurations.

Encryption protects ePHI in HIPAA compliant cloud storage by making the data unreadable without the right key. But who controls that key matters.

There are three common options:

• Provider-managed keys: The cloud provider creates, stores, and manages the keys for you. It is the easiest option but gives you the least control.
• BYOK (Bring Your Own Key): You create the keys and add them to services like AWS KMS or Azure Key Vault. You control when they are changed or disabled, but the keys are still stored with the cloud provider.
• HYOK (Hold Your Own Key): You keep the keys in your own HSM or external key system. The cloud provider only gets encrypted data and cannot access the keys.

For most organizations using HIPAA compliant cloud storage, BYOK is a practical middle ground.

Here’s why the choice matters more than it looks. HIPAA’s Breach Notification Rule only applies to unsecured PHI. If data was encrypted before an incident and the key wasn’t compromised, there’s no notification obligation. That’s the safe harbor, and HHS points to NIST SP 800-111 for data at rest and FIPS 140-2 for data in transit.

Read the condition again. PHI is not secure if the key was breached too. Provider-managed keys put the keys and the data in the same blast radius. If an attacker reaches the provider’s key management plane, the safe harbor stops applying.

HHS proposed a rule in January 2025 that would make encryption of ePHI mandatory at rest and in transit, removing the “addressable” designation. It would also require MFA for every system accessing ePHI, 72-hour incident reporting, and a written annual attestation from business associates.

Be precise about status: as of mid-2026, there is no final rule, and OMB now targets July 2027. Once published, most provisions require compliance about 240 days later.

So pick a setup that already supports mandatory encryption, MFA on every path to ePHI, and a BA that can produce a written attestation. These controls are becoming increasingly important when evaluating cloud based storage HIPAA compliance.

HIPAA compliant cloud storage and cloud backup do different jobs. Understanding the difference is an important part of cloud based storage HIPAA compliance, especially when planning backup and recovery controls.

HIPAA compliant cloud storage keeps your files and data available so authorized people and apps can use them while applying the controls required to protect ePHI. It’s what lets you pull up patient records, share files, and work together across different locations.
For HIPAA regulated data, you need to control who can access ePHI and what they can do with it. Access controls, permissions, MFA, encryption, and audit logs all help protect ePHI in your main storage system.

Cloud backup keeps separate copies of your data so you can restore them if something is deleted, a system fails, files are corrupted, or a security incident occurs.

A good backup plan should define how far back you can restore and how long backups are kept.

HIPAA’s Security Rule requires covered entities to have a plan for emergencies and for getting access to ePHI back when systems go down. Just storing your data in the cloud doesn’t cover this.

Your contingency plan should explain how you’ll back up data, recover from a disaster, and keep things running during an emergency. It’s also important to test the plan regularly so you know it will work when you need it.

Immutable backups cannot be changed or deleted for a set period. This helps keep ransomware from wiping out the backup copies you need to recover your data.

S3 Object Lock has two modes. Governance mode lets authorized admins override the protection, while Compliance mode does not allow the data to be changed or deleted until the retention period expires, even by the root account.

Compliance mode gives you stronger protection if an attacker gets admin access. Azure has similar protection through immutable blob policies. You can also use versioning and MFA Delete for extra protection.

These features are not automatically turned on, so your team needs to configure them properly.

Even with HIPAA compliant cloud storage, ePHI doesn’t always stay in your main storage or database. Copies can also end up in backups, logs, test environments, analytics tools, and third-party services. These extra copies are easy to overlook and can create security and compliance risks.

Cloud systems create backups, snapshots, replicas, and disaster recovery copies automatically. These copies contain the same ePHI as the original data.

For cloud based storage HIPAA compliance, each copy should be included in access, encryption, retention, and deletion reviews.

Cloud providers and other vendors may keep backups, support data, or temporary copies to run their services. Sub-processors may also process or store your ePHI.

Know where your ePHI goes, who can access it, and how long it stays there. Your contracts and BAAs should clearly spell out who is responsible for these copies.

Applications can accidentally put patient names, IDs, medical details, or other ePHI into logs and error messages. Search indexes and monitoring tools can also create extra copies.

Limit what your applications log, protect access to logging systems, and avoid sending unnecessary ePHI to analytics or monitoring tools. This is another area that can be overlooked during a cloud based storage HIPAA compliance assessment.

Development and testing environments can also expose ePHI. Teams sometimes copy real patient data into staging because it makes testing easier.

Use de-identified or synthetic data whenever possible. If ePHI must be used, apply the same security and compliance controls used in the production environment.

AI systems can create more copies of healthcare data through prompts, model inputs, embeddings, vector databases, caches, and testing datasets.

Before sending ePHI into an AI system, identify every system that receives or stores the data. Make sure the required security controls and contractual protections are in place.

There is no single best HIPAA compliant cloud storage provider. The right option depends on how your organization uses ePHI, how much control your IT team needs, and how much infrastructure you want to manage.

Managed HIPAA hosting bundles infrastructure, security controls, and compliance services into one package. Compare the actual security controls, BAA terms, backup provisions, and support model before choosing, since “managed” means different things at each vendor.

File sync and sharing platforms are built for everyday access, collaboration, and secure file exchange. They can work well for healthcare teams whose employees need to access documents across devices and locations.

Before storing ePHI, check three things: your plan tier is BAA-eligible, the BAA is signed, and the services you use sit inside its scope.

For example, Dropbox includes the BAA with Business and higher plans, not Free or Basic. Google Drive requires a super admin to accept the Google Workspace BAA. OneDrive supports commercial plans, not personal plans. Box includes it with Business and Enterprise plans.

A BAA may not cover every feature, either. For example, Dropbox’s Dash AI search is outside its BAA. Always check the vendor’s HIPAA documentation before enabling new features that may handle ePHI.

Object storage can be a strong foundation for HIPAA compliant cloud storage when you’re handling large volumes of unstructured data, application-generated files, backups, and archives.

Platforms like AWS S3, Azure Blob Storage, and Google Cloud Storage come with extensive security and configuration options.

The catch is that your team is responsible for setting up those controls correctly. A HIPAA-capable cloud platform doesn’t make a misconfigured storage environment compliant on its own.

If a provider will handle ePHI on your behalf, you need a BAA. Don’t assume a popular consumer service is fine just because it offers encryption. If a provider won’t sign a BAA for the service you plan to use, pick something else.

Northeast Radiology ran a PACS server holding patient radiology images. Unauthorized individuals accessed those images between April 2019 and January 2020. The practice notified 298,532 patients. The intrusion went undetected for roughly ten months.

OCR found the practice had never conducted an accurate risk analysis of where ePHI sat and what protected it. In April 2025, it agreed to pay $350,000 and follow a two-year corrective action plan. The exposure ran through its vendor, Alliance HealthCare Services.

Key lesson: The problem was not just the break-in. The organization had not properly identified and assessed where ePHI was stored and how it was protected. Working with a vendor does not remove your responsibility to understand and manage those risks. (Source)

A cloud provider’s breach does not automatically mean your organization has 60 days to notify patients. Under HIPAA, the covered entity or business associate responsible for the breach has specific notification duties. The timing depends on who found the breach and what the BAA requires.

Under 45 CFR 164.410(b), a business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after it discovers the breach. The covered entity then decides what goes to individuals, HHS, and, in some cases, the media.

Here’s the part most teams get wrong: when your clock actually starts. If the business associate is acting as your agent, its discovery is imputed to you. Your 60 days began the day the vendor found the breach, not the day it emailed you. If it’s an independent contractor, your clock starts on notification.

That can eat most of your window before you know an incident exists. So put real numbers in the BAA. Require notification within 5 to 10 days of discovery, not 60. Define whether the vendor is acting as your agent, in writing.

Healthcare applications often need more than a secure place to store files. They may need databases, APIs, identity management, audit logging, backups, analytics, and controlled access to ePHI across multiple systems.

A HIPAA compliant cloud storage architecture on AWS or Azure should separate sensitive data from application components and apply controls such as encryption, least-privilege access, network segmentation, centralized logging, backups, and monitoring.

The exact services and configuration matter. Using a HIPAA-eligible cloud service does not automatically make the entire application HIPAA compliant.

Distributed teams can increase the number of people and systems that may access ePHI. Use role-based access, least privilege, MFA, audit logging, and time-limited access to reduce unnecessary exposure.

Developers should generally work with de-identified or synthetic data instead of production PHI wherever possible.

Your cloud provider may rely on subcontractors or other service providers for infrastructure, support, monitoring, or other functions. This creates fourth-party risk because your data can move beyond the vendor you directly contracted with.

Review your provider’s subcontractor and subprocessor arrangements, understand where ePHI may be processed, and ensure contractual obligations extend through the relevant service chain.

The cost of HIPAA compliant cloud storage is not limited to the monthly price of storing files. Healthcare organizations also need to consider retention requirements, backups, retrieval fees, data transfers, security controls, and recovery needs. A lower storage price can become expensive if data is difficult or costly to retrieve when needed.

HIPAA does not generally require covered entities to keep medical records for six years. The six-year HIPAA requirement applies to certain documentation required by the HIPAA rules, such as policies, procedures, and compliance records.

Medical record retention periods can instead come from state laws, payer requirements, accreditation rules, or other regulations. These requirements can vary by location and record type.

Not all ePHI needs the same level of access. Frequently used records can remain in standard storage, while older records that are rarely accessed can move to lower-cost archival tiers.

The gap is bigger than most teams assume. S3 Standard runs $0.023 per GB per month in us-east-1. Glacier Deep Archive runs $0.00099 per GB per month. At 100 TB, that’s roughly $2,250 a month versus $99.

But cheaper storage comes with trade-offs. Deep Archive has a 180-day minimum storage period, so deleting data earlier can still result in charges. Restoring data also takes longer.

Check retrieval time against your contingency plan’s restoration target before moving ePHI there.

Cloud providers may charge for moving large amounts of data out of their platforms. These egress costs can add up during disaster recovery, migrations, investigations, or breach response.

On AWS, data transferred to the internet costs $0.09 per GB for the first 10 TB per month, while cross-region transfers cost about $0.02 per GB. Retrieval fees can also apply. For example, retrieving 10 TB from Deep Archive can cost around $200 and may take up to 12 hours.

These costs can become significant during a major investigation or recovery. For example, retrieving 50 TB of data can add thousands of dollars to the cost of an incident.

Compare the cost of secure storage with the cost of a breach, including response, legal fees, investigation, notification, downtime, and reputation.

Treat security, retention, backup, and recovery as part of the total cost, not as extra costs after choosing a storage price. These factors should be considered when calculating the long-term cost of cloud based storage HIPAA compliance.

Think about how you’ll leave a provider before you sign the contract. Your plan should cover how you’ll move your ePHI, how long the provider will keep it during the move, and when and how it will delete the data.

Before signing up, check the exit terms, export options, migration help, egress fees, and data portability. If the provider uses a format that’s hard to move, switching can take longer and cost more.

After the move, make sure the old provider deletes your ePHI as agreed. Ask for written confirmation of the deletion. Also check backups and other copies. Deleting the main data does not always remove every copy.

A simple exit plan can help you avoid vendor lock-in and keep ePHI safe while you move to a new provider.

At Bacancy Technology, we assist healthcare companies in developing cloud infrastructure that is designed to secure ePHI while still enabling practical application, remote teams, and machine learning processing of data.

Our approach includes:

• HIPAA-ready AWS and Azure architectures designed around access control, encryption, logging, backup, and recovery requirements.
• PHI access governance for distributed and offshore teams using least-privilege access, role-based controls, MFA, and audit trails.
• De-identification pipelines that prepare healthcare data before it reaches AI models, embeddings, or vector databases.
• BAA and fourth-party scope mapping to identify where ePHI moves across cloud providers, subprocessors, and connected services.