Compliance guide · Cloud storage & backup

HIPAA Compliant Cloud Storage and Backup: Requirements, Safeguards, and How to Choose a Provider

HIPAA never certifies a cloud platform. Compliance comes from the business associate agreement you sign and the way you configure the service. This guide covers the Security Rule safeguards that apply to stored PHI, what the contingency plan standard requires of backups, and how to evaluate providers.

BAARequired from the provider
EncryptionAt rest and in transit
Audit logsSix-year retention
Access controlRole-based

Updated September 19, 2026

What HIPAA compliant cloud storage means

HIPAA compliant cloud storage is a service that holds electronic protected health information under a signed business associate agreement, with encryption, access controls, and audit logging configured to satisfy the HIPAA Security Rule. No platform is compliant on its own. Compliance is a property of the configuration and the contract, not of the product.

Healthcare organizations need hipaa compliant cloud storage to protect patient data and meet federal requirements. The right platform helps providers deliver better patient care while keeping every record safe.

This guide explains how hipaa compliant cloud storage works, what features to evaluate, and how business associates and covered entities share security responsibilities.

What Is HIPAA Compliant Cloud Storage?

HIPAA compliant cloud storage is any platform that meets the standards set by the Health Insurance Portability and Accountability Act. The law requires every covered entity to safeguard electronic protected health information using approved technical and administrative controls.

A hipaa compliant cloud storage solution must use strong encryption, access controls, and audit logs to prevent unauthorized persons from reaching sensitive data. Providers that store phi on behalf of a covered entity must also meet these applicable standards.

The hipaa security rule defines the specific technical safeguards that apply to data stored remotely. The hipaa privacy rule governs how organizations handle and disclose protected health information to other covered entities and business associates.

LDR's Mobi-C cervical disc patient site, an award-winning medical website built by Clarity Ventures

Why Organizations Choose Secure Cloud Storage

Secure cloud storage lets healthcare teams access patient data from any location and share files with authorized users across facilities. Cloud computing has changed how providers deliver patient care, and a hipaa compliant solution makes it possible to do so without putting sensitive information at risk.

Organizations that move to secure cloud storage can reduce costs by replacing on-site servers with scalable cloud computing services. Staff can collaborate from mobile devices, access records at the point of care, and share files with other providers in real time.

Secure cloud storage also supports compliance by centralizing data security controls and making it easier to continuously monitor who accesses patient data.

How Compliance Works in the Cloud

Business Associates and BAAs

Any cloud service provider that handles protected health information for a covered entity qualifies as a business associate under hipaa. Business associates must sign a business associate agreement before storing or processing any data on behalf of clients.

The business associate agreement baa outlines each party's obligations, including data security standards and breach notification procedures. Under current rules, business associates are directly liable for violations and can be held contractually liable by the covered entity.

The Department of Health and Human Services enforces these applicable requirements. Hipaa covered entities must verify that every business associate maintains proper safeguards and complies with all hipaa rules.

Shared Responsibility Between Parties

Hipaa compliant cloud storage operates under a shared responsibility model. The provider manages the security of data centers, infrastructure, and the cloud environment. The healthcare organization configures access controls, manages authorized users, and oversees how staff interact with records.

Both parties must document their security responsibilities and maintain records that demonstrate compliance. This division of duties helps organizations stay compliant while letting each party focus on its strengths.

Key Security Features

Strong Encryption

Strong encryption protects data at rest and in transit. Every hipaa compliant cloud storage platform must offer strong encryption with a dedicated encryption key that limits access to authorized users. Data security depends on maintaining these standards across every storage location and data center.

Access Controls and Authentication

Role-based permissions determine who can view, edit, or retrieve records within a hipaa compliant cloud storage platform. Multi factor authentication, granular access controls, and access management policies should limit data to those who need it.

Healthcare providers must configure these settings to align with the security rule and review them on a regular service schedule.

Audit Trails and Monitoring

Audit logs provide a record of every action taken in the system. Audit trails and access logs track who accessed data, when, and what changes occurred. Organizations must continuously monitor their cloud storage activity to identify potential threats and respond before a data security incident occurs.

HIPAA compliant cloud backup and disaster recovery

Storage and backup are different obligations under the Security Rule, and a platform can satisfy one without satisfying the other. A compliant storage tier addresses access control and audit logging. Backup falls under the contingency plan standard, a separate administrative safeguard with its own required implementation specifications.

Backup and storage are not the same requirement

Section 164.312 covers the technical safeguards that apply to ePHI wherever it sits: access control, audit controls, integrity, authentication, and transmission security. Backup is not there. It appears at section 164.308(a)(7), among the administrative safeguards, as the contingency plan standard. The placement matters during an audit, because the evidence a reviewer asks for is different. For storage they want configuration and access logs. For backup they want a written data backup plan, a disaster recovery plan, an emergency mode operation plan, and proof that the copies can actually be retrieved.

What the contingency plan standard requires

Three of its five implementation specifications are required rather than addressable: a data backup plan that creates and maintains retrievable exact copies of ePHI, a disaster recovery plan that restores lost data, and an emergency mode operation plan that keeps critical processes running while systems are down. Testing procedures and criticality analysis are addressable, meaning an organization may document a reasoned alternative but may not quietly skip them.

Required means required. There is no documented-alternative route.

Encryption at rest and the breach safe harbor

Encryption is listed as addressable at section 164.312(a)(2)(iv) for data at rest and 164.312(e)(2)(ii) for data in transit, which is why vendors sometimes describe it as optional. In practice it is not. Under the HITECH breach notification rule, protected health information encrypted to the standards in NIST Special Publication 800-111 is not considered unsecured, and a breach of that data carries no notification obligation. The safe harbor is the strongest practical reason to encrypt, and it holds only if the encryption meets the named standard and the keys were not taken along with the data.

Retention is not one number

HIPAA requires covered entities to retain required documentation for six years from creation or from the date it was last in effect, under section 164.316(b)(2)(i). That rule governs policies, risk analyses, and business associate agreements. It does not govern medical records. Record retention periods come from state law and payer contracts, they frequently run longer, and pediatric records are often held until years after the patient reaches majority. A backup retention schedule has to satisfy the longest applicable period, not the federal minimum.

Deleting a backup early is the one retention mistake that cannot be corrected once discovered, because the evidence is simply gone.

Ransomware changed what a backup has to be

OCR treats a ransomware infection of a system containing ePHI as a presumed breach unless the entity can demonstrate a low probability that the data was compromised. Modern ransomware targets backups first, because an attacker who encrypts the copies removes the only alternative to paying. Object lock, write-once storage, and copies held in a separate account or region under separate credentials are what put a backup beyond an attacker's reach. A backup sitting in the same cloud account as production, reachable with the same credentials, is not a recovery plan.

Three copies, and what actually has to differ

The old rule of thumb held three copies of data on two kinds of media with one copy off site. Cloud storage quietly satisfies the geography and dissolves the media diversity, because three copies inside one provider's object store share a control plane, a billing relationship, and a credential boundary. The modern restatement keeps the count and changes what has to differ: copies should differ in the credentials that reach them, in the account or subscription that owns them, and ideally in the provider that holds them. A second region protects against a data center failure. A second account protects against a compromised administrator, which is the more common way healthcare organizations lose their backups.

Geography is the easy half of that rule to satisfy. Credential separation is the half that most organizations actually skip.

The four-factor assessment OCR expects is specific: the nature and extent of the protected health information involved, including the identifiers present and the likelihood of re-identification; the unauthorized person who used the information or to whom it was disclosed; whether the information was actually acquired or viewed; and the extent to which the risk has been mitigated. Ransomware complicates every one of them, because encryption by an attacker counts as an unauthorized acquisition in OCR's reading, and demonstrating that data was encrypted in place but never removed takes forensic evidence most organizations do not collect by default. Network flow logs, endpoint telemetry, and immutable audit trails are what make that argument available later. Without them the presumption stands and the organization notifies.

Recovery objectives and the restore nobody has run

A recovery point objective is how much data the organization can afford to lose, expressed as time. A recovery time objective is how long it can afford to be down. Neither is a HIPAA term and neither appears in the regulation. They are how the contingency plan standard gets translated into something a vendor can be held to in a service level agreement.

The test that matters is the restore, not the backup job's green checkmark. Restore a real dataset into an isolated environment, confirm it opens, confirm the record counts match, and write down the date. Testing procedures are addressable rather than required, but an entity that has never restored has no evidence its data backup plan produces retrievable exact copies, which is the required part.

Who holds the keys

Key management is where the shared responsibility model stops being abstract. With provider-managed keys the cloud service generates, stores, and rotates the material itself, which is the simplest option to operate and the one most organizations pick; the provider can decrypt your data, which is precisely why the business associate agreement carries the weight it does. With customer-managed keys held inside the provider's key service, the organization controls rotation, access policy, and revocation while the provider still performs the cryptographic work. With customer-supplied keys held entirely outside, the provider never sees the material at all, which maximizes control and means a lost key is permanently lost data. That last option satisfies an auditor quickly and introduces an availability risk the contingency plan standard also covers, so the decision is a trade between two safeguards rather than a straightforward upgrade.

What to ask a provider before signing

Most vendor security pages answer the easy questions. The useful ones are narrower: which specific services the business associate agreement covers, since coverage is rarely account-wide; where data physically resides and whether it can leave that region; what the provider's own recovery point and recovery time objectives are, in writing, as opposed to an uptime percentage; whether immutable or write-once retention is available on the storage class you are actually buying; how long audit logs are retained and whether you can export them; and what the provider will and will not do on your behalf during a restore. Answers to those six questions separate providers far more reliably than a compliance badge does.

Ask the provider for its own restore log. A vendor that cannot produce one has never really been tested either.

The obligation chain runs past your provider

The chain runs further than most organizations map it. A covered entity signs with its cloud provider, which becomes a business associate. Where that provider uses a subcontractor that touches protected health information, and a managed backup service, an offsite key escrow, or a support vendor with production access all qualify, the subcontractor becomes a business associate in its own right, and the provider must obtain satisfactory written assurances from it. Liability follows the chain downward. A covered entity that has never asked which subcontractors handle its data has not finished the diligence the rule contemplates, and learning the answer during a breach investigation is the expensive way to have that conversation.

Backup is where this surfaces most often, because backup is the function organizations are likeliest to have quietly outsourced twice.

Top Providers for HIPAA Compliant Cloud Storage

Google Cloud and Google Drive

Google Cloud offers hipaa compliant cloud services that support hipaa compliance for organizations of all sizes. Google Drive provides secure cloud storage with strong encryption and activity records that meet hipaa requirements. Clients must sign a BAA and configure each service to align with all standards.

Other Compliant Service Providers

Many cloud services offer hipaa compliant cloud storage for healthcare organizations. AWS, Microsoft Azure, Box, and Dropbox Business each provide compliant cloud storage with features that meet applicable standards. When evaluating cloud based services, confirm that each provider offers a BAA, proper permissions, and data centers that meet security standards.

A compliant provider does not make you compliant

The provider secures the infrastructure. Your access control, your configuration and your audit trail stay yours, and that is where findings land.

Talk to an engineer

How to Choose the Right Service

Selecting a compliant cloud storage provider starts with evaluating the service level agreement, security features, and support for hipaa compliance. Confirm that the provider operates data centers with physical and technical safeguards.

Clients should evaluate how the hipaa compliant cloud storage service handles non compliance incidents and whether it can store phi across multiple regions. Every provider must support hipaa compliance throughout the lifecycle of patient data.

Organizations should also review pricing, scalability, and how well the platform integrates with existing cloud services and workflows. Clients that choose a hipaa compliant platform early save time and handle risk more effectively.

Moving PHI into compliant cloud storage

The order below is the one that keeps a migration reversible. Each step produces an artifact an auditor can read.

Inventory where ePHI already lives

Before anything moves, list every system holding protected health information, including the ones nobody sanctioned: shared drives, departmental databases, imaging archives, email attachments, and the laptop belonging to whoever built the first reporting spreadsheet. Migration scope that is wrong at this step stays wrong.

Complete the risk analysis

Section 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to the confidentiality, integrity, and availability of ePHI. OCR asks for this document in nearly every investigation, and its absence is among the most common findings in enforcement actions.

Execute the business associate agreement first

No protected health information moves to the provider before the agreement is signed. HHS guidance on cloud computing is explicit that a service provider storing ePHI is a business associate even when it cannot view the data and holds no decryption key. The conduit exception is narrow and covers transmission, not storage.

Classify data and set the retention schedule

Separate documentation subject to the six-year rule from medical records subject to state retention law, then configure lifecycle policies per class rather than applying one blanket period to everything.

Configure encryption and decide who holds the keys

Encrypt at rest to NIST SP 800-111 and in transit with current TLS. Then decide whether the provider manages the keys, the organization manages them inside the provider's key service, or the organization holds them externally. Each option changes what the provider can recover on your behalf after a failure, which is worth settling before the failure rather than during it.

Migrate in a reversible order

Move a low-criticality dataset first, keep the source system intact and readable, and run both in parallel long enough to compare. Decommissioning is a separate decision made after the restore test passes.

Test the restore, then document it

Restore into an isolated environment, verify integrity, record the date and the result, and schedule the next test. This document is what turns a backup configuration into evidence of compliance.

Everything above produces a document. The documents, not the platform, are what an investigator will ask you to hand over.

Maintaining Compliance over Time

Healthcare providers must treat compliance as an ongoing process. Regular risk assessments, updated access controls, and annual training help organizations manage security across their cloud storage environment.

Business associates should be reviewed each year. Clients should confirm that every service provider continues to meet hipaa requirements and maintains compliant cloud storage configurations.

Cloud computing evolves quickly. New cloud services, updated rules, and changes to data security standards all affect how organizations oversee secure cloud storage. Working closely with each provider and maintaining strong security practices helps protect patient data and deliver better patient care.

What non-compliance actually costs

Penalties are tiered by culpability rather than by the size of the breach, which is why two organizations losing identical amounts of data can face very different outcomes.

Four tiers, set by what you knew

The tiers run from a violation the entity did not know about and could not reasonably have known about, through one due to reasonable cause, to willful neglect corrected within thirty days, to willful neglect left uncorrected. Minimum and maximum amounts per violation rise sharply across the tiers, and the figures are adjusted for inflation each year, so current numbers should be read from the Federal Register rather than from any article.

Each distinct violation counts separately, and a single misconfiguration affecting thousands of records can be counted thousands of times.

Willful neglect is the finding that moves the number

The distinction that pushes an organization into the expensive tiers is rarely technical. It is documentary. An entity with a current risk analysis, signed agreements, and a tested contingency plan is arguing about reasonable cause. An entity without them is arguing about willful neglect.

The sixty-day notification clock

Following discovery of a breach of unsecured protected health information, covered entities must notify affected individuals without unreasonable delay and no later than sixty calendar days. Breaches affecting five hundred or more residents of a state also require notice to HHS and to prominent media outlets within the same period. Smaller breaches are logged and reported annually.

The safe harbor that stops the clock

None of that applies to properly encrypted data. That is the entire point of the safe harbor.

State law stacks on top

Every state has its own breach notification statute, and several impose shorter deadlines, broader definitions of personal information, or attorney general notification duties that HIPAA does not. Multi-state providers comply with the strictest applicable rule, not the federal one.

What OCR asks for first

In practice the opening document request is predictable: the risk analysis, the risk management plan, the policies in effect on the date of the incident, the business associate agreements, evidence of workforce training, and the audit logs covering the relevant period. Organizations that can produce those inside the response window are in a materially different conversation from those reconstructing them afterward.

Most resolutions are not fines. The common outcome is a corrective action plan: a negotiated agreement running one to three years under which the entity revises its policies, completes a fresh enterprise-wide risk analysis, retrains its workforce, and reports to OCR on a fixed schedule. The monetary settlement, where there is one, is frequently the smaller cost. A corrective action plan consumes staff time, outside counsel, and executive attention for years, and it is public. Organizations reading penalty tables sometimes conclude the exposure looks affordable. Organizations that have been through the process rarely describe it that way.

None of this is hypothetical. The enforcement record is published, searchable, and organized by the exact failures described above.

A restore test that failed

Backup jobs report on whether files were copied. They do not report on whether what was copied is enough to bring a system back. The difference usually surfaces at the worst possible moment, which is the argument for surfacing it deliberately instead.

Worked example

A regional radiology group finds out its archive backup was never complete

Six reading sites, roughly 40 TB of DICOM studies, backed up nightly to cloud object storage for four years. The job had reported success every night.

1

Hour 0 — the trigger

A scheduled contingency plan test, not an incident. The compliance officer asks for a restore of one month of studies into an isolated environment.

2

Hour 4 — the copies are there

Roughly 3.1 TB pulls back without error and object counts match the source manifest. On paper the data backup plan is working exactly as documented.

3

Hour 9 — the studies will not open

The DICOM files restore as valid objects, but the archive's index database was never included in the backup set. Without it the studies are unaddressable: present, correctly encrypted, and clinically useless.

4

Day 2 — scope

The gap traces back to the original configuration, which covered the image store path and not the metadata volume. No restore had ever been attempted, so four years of nightly successes had confirmed only that files were being copied.

5

Day 6 — remediation

The metadata volume joins the backup set, object lock is enabled with a retention period matching the state's record requirement, and copies are written to a second account under separate credentials.

6

Day 9 — the second test

A full restore of the same month, index included. Studies open. The date, the dataset, and the result are recorded against the contingency plan's testing procedures.

7

Week 6 — what changed

Restore testing is now quarterly, and the test is a clinical one: a radiologist opens a study. The group's position under 164.308(a)(7) moved from an undocumented assumption to evidence, without a breach having occurred.

Nothing in that sequence required new software. It required someone to ask for the restore before circumstances asked on the organization's behalf.

Frequently asked questions

What makes a platform HIPAA compliant?

A platform is hipaa compliant when the provider signs a business associate agreement, implements strong encryption, maintains audit logs, and meets all security requirements. The covered entity must also configure the service properly.

Do all providers sign a BAA?

Not every cloud storage provider offers a business associate agreement. Healthcare organizations must confirm willingness to sign before storing any protected health information. Providers that decline are not suitable for hipaa compliant cloud storage.

Can teams share files through compliant cloud storage?

Yes. Healthcare teams can share files through hipaa compliant cloud storage if every user follows the security policies and the organization has a business associate agreement in place. Secure cloud storage makes it easier for healthcare providers to collaborate on patient care.

What happens when business associates violate HIPAA?

Business associates that violate hipaa are directly liable for penalties under the Health and Human Services enforcement process. The covered entity may also face consequences for failing to manage the relationship. Non compliance can lead to fines, legal action, and loss of trust from clients and service partners.

How do organizations manage persistent access risks?

Organizations address persistent access by reviewing user permissions regularly, revoking access when staff leave, and using access logs to track all activity. These controls help maintain compliance and protect patient data from potential threats.

Is encryption actually required under HIPAA?

Encryption is addressable, not required, which means an organization may document why an equivalent alternative is reasonable. Very few can. The stronger argument for encrypting is the breach notification safe harbor: properly encrypted protected health information is not unsecured, so losing it triggers no notification obligation.

Does a provider that cannot read our data still need a BAA?

Yes. HHS guidance on cloud computing states that a service provider maintaining electronic protected health information is a business associate even when it stores only encrypted data and holds no decryption key. The conduit exception applies to transmission, not to storage.

How long do HIPAA backups have to be kept?

The six-year rule at 164.316(b)(2)(i) governs required documentation, not medical records. Retention for the records themselves comes from state law and payer contracts and is often longer. Set the backup schedule to the longest applicable period rather than the federal minimum.

What is the difference between HIPAA compliant cloud storage and cloud backup?

Storage is governed by the technical safeguards at 164.312 and is about controlling and logging access to data in use. Backup is governed by the contingency plan standard at 164.308(a)(7) and is about producing a retrievable exact copy when the primary system is gone. A platform can satisfy one and not the other.

How often should a restore be tested?

The rule sets no interval. Testing procedures are an addressable specification, so the organization chooses one and documents the reasoning. Quarterly is a common position for systems holding active clinical data and annually for archives. What matters is that a restore has actually happened and the result was written down.

Does HIPAA certify or approve cloud providers?

No. There is no HHS certification program for cloud services, and a vendor describing itself as HIPAA certified is describing a third-party audit rather than a government approval. Compliance is a property of the configuration and the signed agreement.

Related reading

More on this topic

About the author

Stephen Beer Content Writer, Clarity Ventures Stephen Beer is a Content Writer at Clarity Ventures and has written about various tech industries for nearly a decade. He is determined to demystify HIPAA, integration, enterprise SEO, and eCommerce with easy-to-read, easy-to-understand articles to help businesses make the best decisions. More articles

HIPAA eCommerce

Clarity builds HIPAA compliant healthcare platforms and the infrastructure that keeps them recoverable.

Our team has delivered secure healthcare software since 2007, including patient portals, provider directories, and integrated clinical systems running under signed business associate agreements. We handle the architecture, the safeguards, and the documentation behind them. Tell us what you are storing and where it lives now, and we will tell you what the migration actually involves.

2007Building healthcare software since
BAASigned on every engagement
24/7Monitoring and support