Skip to content
Edited by Jessica Eisenberg, Sr Global Campaigns · Last reviewed: June 2026
Cloud backup is HIPAA compliant when the provider will sign a Business Associate Agreement, encrypts your data at rest and in transit, controls and logs access to it, and can produce retrievable exact copies you’ve actually tested. Miss any one of those and the backup itself becomes a compliance gap, no matter how reliable the technology is.
This matters because HIPAA treats backup as mandatory. The Security Rule’s contingency plan standard requires a documented Data Backup Plan, so any healthcare team running AWS or Azure has to back up ePHI and then prove the setup meets the rule.
For the full regulatory picture, start with the HIPAA compliance guide. (coming soon)
Below: what HIPAA requires of your backups, the criteria that separate a compliant solution from a risky one, and how the main options compare.
In this article:
- What HIPAA requires of your backups
- What a HIPAA disaster recovery plan covers
- What makes a cloud backup solution HIPAA compliant
- Top HIPAA compliant cloud backup solutions compared
- What to configure in AWS and Azure
- How N2W handles HIPAA backup requirements
- Where backups go wrong (and become a penalty)
- Frequently asked questions
What HIPAA requires of your backups
Three required specifications under the contingency plan standard (45 CFR §164.308(a)(7)) drive everything:
- Data Backup Plan (§164.308(a)(7)(ii)(A)): create and maintain retrievable exact copies of ePHI. “Retrievable” is the operative word. A backup you can’t restore doesn’t satisfy the spec.
- Disaster Recovery Plan (§164.308(a)(7)(ii)(B)): procedures to restore lost data after an incident.
- Emergency Mode Operation Plan (§164.308(a)(7)(ii)(C)): keep critical processes running while you recover.
On top of those, the technical safeguards (45 CFR §164.312) apply to the backup copies themselves. The data needs access controls, audit logging, integrity protection, and encryption. Encryption carries a bonus: under the Breach Notification Rule, properly encrypted ePHI that’s exposed may qualify for safe harbor, which can take a breach notification off the table entirely. The HIPAA safeguards breakdown covers how each of these maps to specific controls.
So a HIPAA compliant backup holds ePHI under the same safeguards the original data requires, plus a recovery process you can prove works. One feature alone never gets you there.
What a HIPAA disaster recovery plan covers
Backups satisfy the Data Backup Plan spec. The Disaster Recovery Plan spec (§164.308(a)(7)(ii)(B)) asks a different question: when ePHI is lost, how do you get it back and keep care running? A workable plan covers four things.
- Disaster declaration. Name who decides an event counts as a disaster, and the criteria that trigger recovery. Without a clear trigger, teams lose hours debating whether to act.
- Disaster list. You can’t plan for every scenario, so focus on the high-impact events most likely to hit your environment: ransomware, accidental deletion, a region outage.
- Health data retrieval. Spell out how backed-up records get restored and in what priority. This is where the plan points back to your Data Backup Plan and the recovery point objective your operations can tolerate.
- Alternate site. Define where operations run while you recover. A cloud-native setup makes this far simpler than on-premises: you fail over to a standby environment inside your existing AWS or Azure account instead of standing up replacement hardware.
Write each step down, assign it an owner, and test it. An untested recovery plan fails you the same way an untested backup does, on the day you need it most.
What makes a cloud backup solution HIPAA compliant
When you’re evaluating tools, these are the criteria that actually decide it. Treat the first one as a hard filter.
1. The vendor signs a BAA. A backup provider holds a copy of your ePHI, which makes them a business associate. The 2013 Omnibus Rule extended HIPAA’s compliance obligations to business associates directly, so a cloud backup vendor carries its own liability for the ePHI it stores. Without a signed Business Associate Agreement, you can’t legally send them PHI, full stop. This eliminates a surprising number of consumer-grade and even some commercial tools before you look at any other feature. One nuance worth knowing: this requirement applies to tools that receive a copy of your PHI. Software that runs inside your own cloud account and never sends PHI to the vendor doesn’t make that vendor a business associate, so there’s no BAA to sign with them.
2. Encryption at rest and in transit. AES-256 at rest and TLS in transit is the practical baseline. Confirm you control the keys or understand who does.
3. Access controls and audit logging. Unique user IDs, role-based permissions, and logs that let you reconstruct who accessed or restored data. Auditors ask for these.
4. Immutability against ransomware. Backups are a primary ransomware target, because attackers know an organization with no clean recovery copy is more likely to pay. Immutable backups can’t be altered or deleted during a retention window, even by an admin account or a piece of malware. This is the difference between having backups and being able to recover from an attack.
5. Retention and tested restores. The solution should let you set retention policies that match your data’s requirements, and make restore testing easy enough that you do it regularly. An untested backup is a guess.
6. Data stays in covered, controlled infrastructure. The backup should land in HIPAA-eligible services and ideally inside your own cloud account, so ePHI never moves into a service the BAA doesn’t cover.
7. Documentation, audit trails, and compliance reporting. The system should maintain detailed, and regularly updated compliance records of backup operations, restore events, configuration changes, and administrative actions. These audit trails should be easily exportable for auditors or internal security reviews.
8. Inventory and tagging for PHI awareness. A compliant system should support tagging or classification of backup data (e.g., marking datasets as containing ePHI). This enables organizations to maintain an updated and accurate inventory of sensitive data, apply differentiated retention policies, and ensure PHI is consistently governed across environments.
Top HIPAA compliant cloud backup solutions compared
There’s no official “HIPAA certified” backup product. Any vendor claiming certification is overstating it. What you’re really comparing is how well each option meets the criteria above for your AWS or Azure environment. Confirm BAA availability and scope directly with any vendor before you commit, since terms change.
| Solution | Best for | BAA | AWS/Azure native | Immutable backups | Shortest RPO | Built-in Complete Restore testing |
|---|---|---|---|---|---|---|
| N2W Backup & Recovery | AWS and Azure cloud-native backup and DR | Not needed (data stays in your account) | Yes, agentless | Yes | 60 seconds | Yes, automate scheduled full environment restores |
| AWS Backup | Single-account AWS shops staying fully native | Via AWS BAA | AWS only | Yes (Vault Lock) | Per backup plan | Only manual, scripted restore testing |
| Azure Backup | Azure-only workloads | Via Microsoft BAA | Azure only | Yes (immutable vaults) | Per policy | Must incorporate Azure Site Recovery or custom scripts for restore testing support |
| Veeam | Hybrid and on-prem plus cloud | Available | Multi-platform, agent-based | Yes | Per job | Requires scripting or a separate orchestration layer for full environmental restore |
| Commvault / Rubrik | Large enterprise, broad governance | Available | Multi-platform | Yes | Per policy | Requires additional configuration for full end-to-end cloud rebuilds |
A few honest notes on the trade-offs:
Native cloud tools (AWS Backup, Azure Backup) are covered under the provider’s BAA and are a reasonable starting point if you live in one cloud. The limits show up with cross-account isolation, multi-cloud coverage, and granular recovery point objectives.
Traditional enterprise backup (Veeam, Commvault, Rubrik) brings broad coverage across on-prem and cloud, which fits if your healthcare estate is hybrid. The trade-off is heavier architecture and agents to manage, and cost that climbs at scale.
Cloud-native third-party backup (N2W) sits between them: deeper than the native tools on recovery and cost control, lighter than the enterprise suites, and focused specifically on public cloud.
What to configure in AWS and Azure
The tool is half the job. The configuration is the other half, and it’s the part you own under the shared responsibility model. At a minimum: keep ePHI in HIPAA-eligible services, enable encryption everywhere, lock down IAM so backup and restore are least-privilege, turn on logging (CloudTrail on AWS, the equivalent on Azure), and enable immutability or vault locking on the backup target.
Platform specifics differ enough to need their own walkthroughs.
How N2W handles HIPAA backup requirements
N2W runs entirely inside your own AWS or Azure account and never receives or stores your ePHI. Your backups stay in the cloud services your existing AWS or Microsoft BAA already covers, so N2W doesn’t become another business associate in your compliance chain or hand you another BAA to negotiate and manage.
The only thing N2W receives from your environment is a license check confirming which software version you run, never your data. It backs up as often as every 60 seconds, which gives you a tight recovery point objective and satisfies the retrievable-copies spec with current data. Backups can be made immutable, so ransomware or a compromised admin account can’t tamper with your recovery copies. And the cost angle is real for healthcare teams watching cloud spend: N2W reports up to 92% storage savings versus storing native snapshots long-term.
Because N2W runs on AWS and Azure and routes its operations through their APIs, it works entirely within those providers’ HIPAA-eligible, SOC- and ISO-audited infrastructure. AWS, for example, publishes SOC reports independently audited by Ernst & Young. That doesn’t make N2W a “HIPAA compliant product” by itself, since no backup tool is. What it means is that the platform underneath meets those audited standards, and your configuration does the rest.
N2W also supports:
- Point-in-time recovery for Amazon S3 buckets, allowing teams to restore objects to a specific state before corruption
- Fully automated restore testing capabilities including all network configurations
- Clear, easy-to-access documentation of backup policies, permissions and configuration history
- Live visibility into unprotected or non-compliant resources across the environment, making it easier to identify workloads that are at risk
Healthcare and life-sciences organizations including Johnson & Johnson run their cloud backup on N2W. You can start a free trial or book a demo to see the configuration that satisfies the Data Backup Plan and Disaster Recovery Plan specs.
Where backups go wrong (and become a penalty)
Inadequate backup and recovery shows up repeatedly in HHS settlements, usually because data couldn’t be restored after a ransomware attack or because backups were never tested. The common failures are avoidable: no immutability so ransomware encrypted the backups too, no signed BAA with the backup vendor, ePHI copied into a service the BAA didn’t cover, or a restore process nobody had run until the day they needed it.
Frequently asked questions
A signed Business Associate Agreement with the provider, encryption of the backed-up ePHI at rest and in transit, access controls and audit logging, and retrievable exact copies you can actually restore. The backup has to meet the same Security Rule safeguards as the original data.
Yes, if the vendor receives or stores your ePHI. Holding a copy of your PHI makes a vendor a business associate, and you need a signed BAA before sending it any PHI. A vendor that won’t sign one can’t legally hold your healthcare data. The exception is software that runs inside your own cloud account and never receives your PHI, like N2W: nothing leaves for the vendor to hold, so there’s no BAA to sign and your existing AWS or Microsoft BAA covers the storage.
The services are eligible under the AWS and Microsoft BAAs, but the tool alone doesn’t make you compliant. You’re responsible for configuring encryption, access controls, logging, retention, and immutability, and for keeping ePHI in covered services.
Encryption is technically an addressable specification rather than a strict requirement, but in practice you should always encrypt. The cost is low, and encrypted ePHI that’s exposed may qualify for breach-notification safe harbor.
HIPAA doesn’t name a specific frequency. It requires retrievable exact copies, and your backup frequency should follow from your own risk analysis and the recovery point objective your operations can tolerate.
Sources
- 45 CFR §164.308: Administrative safeguards (contingency plan, Data Backup and Disaster Recovery Plans), eCFR
- 45 CFR §164.312: Technical safeguards, eCFR
- Breach Notification Rule guidance: encryption and safe harbor, U.S. Department of Health & Human Services
- Guidance on HIPAA & Cloud Computing: business associate status, U.S. Department of Health & Human Services
- Summary of the HIPAA Security Rule, U.S. Department of Health & Human Services
About the author
Catalin Voicu is a Systems Engineer at N2W who works hands-on with backup and disaster recovery for HIPAA-regulated workloads on AWS and Azure.
This article is for general informational purposes and is not legal advice. HIPAA compliance depends on your specific environment, data, and obligations. Consult a qualified healthcare compliance professional or attorney before making compliance decisions.