Choosing a Disaster Recovery Site: Where Your Business Runs When the Office Cannot

A HIPAA-compliant backup is an exact, restorable copy of your electronic protected health information. It is protected as carefully as the original, and it sits inside a written contingency plan you have tested. HIPAA does not approve or certify any backup product. It requires a plan, a process, and evidence that both work, which is why two practices using the same backup software can land on opposite sides of an audit.

The stakes have risen with ransomware, and HHS has warned that some variants go after online backups as well as the systems they protect. This guide walks through the HIPAA backup requirements in the Security Rule, what to look for in a backup solution, and who is responsible for each copy of practice data. It also covers how to test and document the work, and what the proposed HIPAA update would add.

What HIPAA Requires: The Contingency Plan Standard

The HIPAA contingency plan standard requires covered entities and business associates to have policies and procedures for emergencies that damage systems containing electronic protected health information. The rule's own examples are fire, vandalism, system failure, and natural disaster. The standard breaks into five parts, three required and two addressable:

• Data backup plan (required): procedures to create and maintain retrievable, exact copies of electronic protected health information.
• Disaster recovery plan (required): procedures to restore any loss of data.
• Emergency mode operation plan (required): procedures that keep critical business processes running, with patient information still protected, while the practice operates in emergency mode.
• Testing and revision procedures (addressable): periodic testing and revision of the contingency plan.
• Applications and data criticality analysis (addressable): an assessment of which applications and data matter most, used to guide the rest of the plan.

Addressable does not mean optional. You implement the specification when it is reasonable and appropriate for your practice, or document why not and what you do instead. For backup testing and criticality analysis, it is very hard to argue that neither applies.

The Data Backup Plan

The phrase that matters is retrievable, exact copies. A backup that completes every night but has never been restored proves nothing. A copy that misses the imaging archive or the scanned intake forms is not a complete copy of your patient information either. The plan should name every system that holds patient data, how often each is backed up, where the copies live, and how long they are kept.

The Disaster Recovery Plan

A HIPAA disaster recovery plan turns copies back into a working practice. It sets which systems return first, who does the work, where restored systems run if the office or server is unavailable, and how long each step should take. Many small practices rely on outside disaster recovery services for this part, because rebuilding a server from backup at midnight is not a skill most office managers keep sharp.

Emergency Mode Operation

Emergency mode is the stretch between the failure and the recovery. The plan should explain how the practice keeps seeing patients, for example with paper schedules and printed encounter forms. It should also explain how security controls stay in place while systems are down, since a crisis is exactly when people start sharing passwords and emailing records from personal accounts.

Testing and Criticality

The two addressable parts are what make the other three credible. A criticality analysis ranks your systems by how badly the practice suffers without them, which sets the restoration order and the recovery targets. A business impact analysis is the practical way to produce it.

Testing then proves the targets are real. Restore a file, a database, and eventually a whole system on a schedule. Write down what happened, and revise the plan whenever a test exposes a gap.

What to Look For in a HIPAA-Compliant Backup Solution

A compliant plan still depends on backups built to protect patient information, whether you run them yourself or through a managed data protection service. In practice, the HIPAA data backup requirements translate into these properties to check:

• Complete coverage of every system that stores patient information, including imaging workstations, scanned documents, and cloud applications.
• Encryption of backup data at rest and in transit.
• Multifactor authentication and limited administrator access on the backup console.
• At least one copy that ransomware cannot alter or delete, either offline or immutable.
• An offsite or cloud copy, so a fire or theft at the office does not take the backups with it.
• A business associate agreement with every vendor that stores or manages the backups.
• Alerts that someone reviews, so a failed job is noticed within a day, not a month.
• Secure destruction of retired backup drives and media.

The 3-2-1 backup rule is a sound baseline for most practices: three copies of the data, on two different types of storage, with one copy kept offsite. It is a design pattern, not a legal requirement, but it covers most of the failures a small practice is likely to face.

Encryption and the Breach Safe Harbor

Encryption does double duty for backups. Patient information encrypted to the standard in HHS guidance is not considered unsecured. A properly encrypted backup drive that is lost or stolen may therefore not trigger breach notification, while the same loss with an unencrypted drive usually means notifying patients.

Your Backup Vendor Is a Business Associate

HHS guidance on cloud computing is explicit on this point. A cloud provider that stores electronic protected health information is a business associate, even if the data is encrypted and the provider has no key to read it. Using such a service without a business associate agreement is a HIPAA violation on its own. Collect a signed BAA from the backup vendor and from any IT provider that manages the backups for you.

Ransomware Changes the Design

HHS treats ransomware as a security incident. When ransomware encrypts patient information, a breach is presumed unless the practice can show a low probability that the information was compromised. HHS also recommends frequent backups, periodic test restores, and backups kept offline or otherwise out of the network's reach, because some ransomware variants go after online backups first.

That is the case for immutable backups, which cannot be changed or deleted during their retention period, even by an administrator account an attacker has taken over. For a small practice, one immutable or offline copy can be the difference between restoring from backup and facing a ransom demand with no alternative.

Where Practice Data Lives, and Who Backs It Up

Responsibility for backups follows the data, and in many practices the data is spread across more places than the owner realizes. Map each location and name who is responsible for its copies:

• An on-premises server running practice management or EHR software: the practice, usually through its IT provider.
• A cloud-hosted EHR or practice management system: the vendor, under its BAA, although the practice should confirm how backups work and how it can export its own data.
• Imaging systems for X-rays, CT, or scans: usually local and very large, so they need their own backup and retention plan.
• Microsoft 365 or Google Workspace: shared, because the platform keeps the service running, but its retention settings do not replace a backup of your data.
• Workstations and laptops: they should not store patient information locally, and if they do, they belong in the backup plan.

The cloud applications are where practices assume too much. Retention settings and recycle bins keep data inside the same service, not as an independent copy. The reasons cloud apps like Microsoft 365 still need their own backup carry extra weight when the mailbox holds patient records.

Questions to Ask a Cloud EHR Vendor

Vendor-hosted systems move the work but not the accountability. Ask how often the vendor backs up your data, where the copies are stored, and how quickly it can restore your practice after an outage. Ask how you would get a complete export of your records if you left. Make sure the answers appear in the contract or BAA, not only in a sales email.

Testing Restores: The Evidence That Holds Up

A backup program earns trust through restores, not green checkmarks on a dashboard. Test at a few levels: restore individual files regularly, restore a database or application periodically, and rehearse a full system recovery at least once a year. Record each test with the date, what was restored, how long it took, and what went wrong.

Measure each result against the recovery targets from your criticality analysis. Those targets define how much data the practice can afford to lose and how long it can operate without each system. The mechanics of how to test a backup properly matter as much as the schedule, since a test that restores to the same server it came from can hide problems a real disaster would expose.

Documentation That Proves Compliance

If it is not written down, an auditor will treat it as not done. Keep these records together and current:

• The written contingency plan, with its last review date.
• The inventory of systems that hold patient information and their backup schedules.
• Retention periods for each type of backup.
• Signed BAAs with backup vendors and IT providers.
• Restore test logs and the fixes that followed.
• Records of any real incidents and how the recovery went.

HIPAA requires security documentation to be kept for six years from its creation or the date it was last in effect, whichever is later. Keep old versions of the plan and old test logs instead of overwriting them. Review the whole set at least once a year and whenever the practice changes systems.

What the Proposed HIPAA Update Would Add

In January 2025, HHS proposed the largest update to the Security Rule in years, and backups feature prominently in it. The proposal would require written procedures to restore critical systems and data within 72 hours of a loss. It would also require a formal criticality analysis to set restoration priorities, separate technical controls for backup and recovery, and testing of contingency plans at least once every 12 months. Every implementation specification would also become mandatory, ending the distinction between required and addressable.

It would also require business associates, including IT and backup providers, to notify covered entities within 24 hours of activating their contingency plans. The proposal is not final, and HHS currently lists July 2027 as the projected date for final action. Practices that already meet these targets will have little to change if it becomes law.

Backup Gaps That Show Up in Medical and Dental Practices

The same weaknesses appear in small practices again and again. Check your setup against this list:

• The server is backed up, but the imaging workstation or the front desk scanner folder is not.
• The backup drive stays plugged into the server, where ransomware can reach it.
• The cloud backup account uses the same administrator password as the rest of the network.
• Nobody reads the backup failure alerts.
• The backup has never been restored, or was last tested years ago.
• The backup vendor never signed a BAA.
• Old backup drives sit in a closet after replacement.

Many of these can be fixed in an afternoon once someone owns the problem. The expensive version is discovering them during an outage.

Building a HIPAA-Compliant Backup Plan

A HIPAA-compliant backup comes down to three things you can prove. You have complete, protected copies of every system holding patient information, a written plan for restoring them, and test results showing the plan works. None of it requires exotic technology, only a clear inventory, the right agreements, and a habit of testing.

Review the arrangement each year alongside your risk analysis so it keeps pace with new systems, new staff, and new vendors. The practices that recover quickly are the ones that rehearsed before they needed to.

Recovery is also a local problem. When a server fails or an office floods, someone has to arrive with replacement hardware and the restore plan in hand. For practices in Simi Valley and across Ventura County, that means a team that knows the environment before the emergency, not one learning it during the outage.

If you want to know whether your backups would hold up in an audit or an outage, GlobeVM can review your contingency plan, test a restore with you, and close the gaps it finds.