Every practice has a backup. Fewer have one they have restored from. Fewer still have one that would survive an attacker who already holds the domain administrator account, which is what ransomware crews arrange before they encrypt anything. HIPAA does not tell you which product to buy. It tells you what the outcome has to be, and expects you to prove it.
What HIPAA requires: the contingency plan standard
The Security Rule's contingency plan standard (45 CFR 164.308(a)(7)) governs backup. It has five parts. In plain terms:
- Data backup plan. Required. Procedures to create and maintain retrievable exact copies of electronic PHI. "Retrievable" is doing a lot of work in that sentence. A backup you cannot restore does not meet it.
- Disaster recovery plan. Required. Procedures to restore any loss of data: which systems, in what order, from which copies, by whom.
- Emergency mode operation plan. Required. How the practice keeps protecting ePHI and keeps seeing patients while systems are down. Paper charting, phone triage, and who may do what during an outage.
- Testing and revision procedures. Addressable. Periodically test the plans and revise them. "Addressable" does not mean optional; it means you implement it or document why an alternative is reasonable. There is no reasonable alternative to testing your restores.
- Applications and data criticality analysis. Addressable. Decide which systems matter most so recovery is prioritized. The EMR comes back before the marketing website.
None of that names a frequency, a retention period, or a technology. Those choices come out of your risk analysis and must be documented. When OCR investigates a ransomware incident, the questions are predictable: did you have a backup plan, was it in writing, was it tested, and did it work.
3-2-1, plus the part that stops ransomware
The old rule of thumb is still the right starting point: three copies of your data, on two different media or platforms, one copy off-site. A local appliance plus a cloud copy satisfies it.
The modern addition is what makes it ransomware-proof: at least one copy has to be immutable and isolated from your administrative credentials.
Immutable means the backup cannot be altered or deleted for a defined period, even by an administrator: object lock on cloud storage, write-once retention, or a hardened append-only repository. Isolated means the credentials that run your network cannot reach and delete the backup. If your backup console uses the same domain admin account as the file server, and the attacker has that account, the attacker has your backups.
The standard ransomware playbook includes days or weeks inside a network before encryption, and one of the first tasks is finding and deleting backups. Our article on why ransomware targets medical practices covers the pattern. The defense is a copy the attacker cannot touch after they own everything else.
What to back up
Practices frequently protect the server and forget the rest.
On-premise EMR or practice management database. If you host eClinicalWorks, NextGen, or another system on a server in a closet, this is the crown jewel. Use application-aware backups (SQL or the vendor's supported method) that produce a consistent copy, not a file-level snapshot of a running database.
Imaging. Dermatology photo archives, X-ray and DEXA studies, ultrasound, PACS, in-office lab instrument data. These are large, grow fast, and often sit on a workstation nobody thinks of as a server. They are ePHI.
File shares and scanned documents. Insurance cards, consent forms, referral faxes, HR files, and the spreadsheets that run the practice.
Microsoft 365 or Google Workspace. Email, OneDrive, SharePoint, Teams, Drive. Retention and hold are not backup. A third-party backup stored outside the tenant and your admin credentials is. See Microsoft 365 for medical practices.
Vendor-hosted data. If your EMR is cloud-hosted, the vendor backs it up for their own continuity. What you usually do not get is a copy in your possession. Ask what data export the vendor provides and how you would obtain your records if the vendor were breached or you decided to leave. Periodic exports to storage you control are cheap insurance.
Configurations. Firewall and switch configs, server documentation, license keys, and passwords, stored somewhere that survives the incident.
RTO and RPO in plain language
Two terms drive backup design.
Recovery Point Objective (RPO) is how much data you can afford to lose. If your last good backup was at 6 PM yesterday and the server dies at 3 PM today, you have lost a day of charting, orders, and payments. Most practices land between 15 minutes and 4 hours once they think about re-keying.
Recovery Time Objective (RTO) is how long you can afford to be down: not how long the restore takes on paper, but how long from "it broke" to "we are seeing patients in the EMR again." For a pain management clinic with procedures scheduled, half a day is a serious problem. Our article on the cost of IT downtime for a medical practice puts numbers around it.
Practical examples:
| System | Reasonable RPO | Reasonable RTO | What it takes |
|---|---|---|---|
| On-prem EMR/PM database | 15 min to 1 hour | 2 to 4 hours | Frequent snapshots, local appliance with instant virtualization, cloud replica |
| Imaging archive | 24 hours | 1 to 2 days | Nightly backup, cloud copy, restore to a spare workstation |
| File shares | 4 to 24 hours | 4 to 8 hours | Snapshots plus nightly cloud backup |
| Microsoft 365 | 24 hours | Hours for a mailbox, days for a full tenant | Third-party SaaS backup with granular restore |
| Cloud-hosted EMR | Vendor's SLA | Vendor's SLA | Read the contract, keep exports |
Tighter numbers cost more. Looser numbers cost more when something happens. The right answer is a business decision, and it belongs in your criticality analysis.
Testing, encryption, and vendor BAAs
Restore testing: cadence and evidence
A backup that has never been restored is a hypothesis. A cadence that holds up in a risk analysis:
- Daily. Automated job verification, with failure alerts a human actually reads. Many platforms can boot a backup image and screenshot the login screen.
- Monthly. Restore a handful of files or a single mailbox to an alternate location. Confirm they open. Log it.
- Quarterly. Restore the EMR database or a full server to an isolated environment and confirm a chart can be opened. Log start time, end time, who did it, and what went wrong.
- Annually. A tabletop or live disaster recovery exercise. Walk the emergency mode plan with clinical and front-desk staff, then revise it.
The evidence is the point. Restore logs, screenshots, and dated exercise notes turn "we have backups" into a documented, tested contingency plan. They are also what a cyber insurance carrier wants when it asks whether backups are tested.
Encryption and BAAs with backup vendors
Backups are ePHI. They must be encrypted at rest and in transit, with keys kept apart from the backup. A misplaced external drive holding an unencrypted server image is a reportable breach; the same drive encrypted with a key the thief does not have generally is not.
Any cloud backup vendor, appliance vendor with cloud replication, or managed backup provider that can access your data is a business associate and needs a signed BAA before data flows. Our article on what a BAA with an IT vendor covers explains what to look for. Whether a specific arrangement requires a BAA is ultimately a legal question, but "cloud storage of patient data" is not a close call.
Three ransomware scenarios and what saves you
Backups deleted. The attacker had domain admin, found the backup server, wiped it, then encrypted production. What saves you: an immutable off-site copy with separate credentials, so deletion requests fail or are reversible within the lock window.
Backups encrypted. The repository sat on a network share the attacker could reach and was encrypted with everything else. What saves you: a hardened repository only the backup service can write to, plus the immutable cloud copy.
Backups too old. The backup was fine, but the intrusion was discovered 40 days after it began, and the clean restore point predates it, so six weeks of records are lost or suspect. What saves you: retention long enough to reach past a slow-moving intrusion (90 days or more of restore points is a reasonable floor), plus logging and EDR that shorten time to detection.
In every scenario, the technical fix is paired with a decision the practice made in advance. That is what the standard asks of you.
Planning for a real outage
Gulf Coast considerations for Houston practices
A Houston practice plans for something a Richardson practice mostly does not: multi-day regional outages. Hurricanes bring flooding, extended power loss, and access restrictions that can keep staff away for a week or more. A backup appliance in a ground-floor closet is a liability in a flood, and a cloud copy is only useful if you can reach it and run from it.
For Houston practices, the off-site copy should be genuinely out of the region, the disaster recovery plan should include running the EMR from the cloud copy while the office is inaccessible, and staff should be able to work remotely with MFA and managed devices already in place. Test it before June, not in September.
The downtime procedure, in one paragraph
Whatever backup you have, the practice needs a written downtime procedure a front-desk lead can follow without calling IT. It should say who declares downtime and how staff are notified; where the paper encounter forms, superbills, and downtime medication lists live; how to verify appointments and insurance from a printed schedule; how prescriptions are handled (including EPCS for pain management practices); who may access what during the outage; how phones are covered; and how everything captured on paper is reconciled into the EMR when systems return. Print it. Put it in a binder. Rehearse it once a year. That, written down and practiced, is your emergency mode operation plan.
Questions to ask your IT provider
- Which systems are backed up, how often, and where does each copy live?
- Which copy is immutable, and what credentials could delete it?
- When was the last full restore test, and can I see the log?
- What are our RTO and RPO for the EMR, and did we agree on those numbers?
- How far back can we restore, and is that longer than a slow intrusion?
- Is Microsoft 365 backed up separately from Microsoft's own retention?
- Do we have BAAs with every backup vendor, and are backups encrypted?
- Where is the written downtime procedure, and when did staff last walk through it?
Quick, specific answers mean you are in good shape. "Let me check" is better heard now than during an incident.
The HIPAA Security Rule's contingency plan standard requires a data backup plan that creates retrievable exact copies of ePHI, a disaster recovery plan, an emergency mode operation plan, and periodic testing. It does not name a specific technology, frequency, or vendor. Those decisions come out of your risk analysis.
Encryption is an addressable specification, meaning you must implement it or document why an equivalent measure is reasonable. In practice, unencrypted backup media holding patient data is a breach waiting to happen, so backups should be encrypted at rest and in transit, with keys kept separate from the backup itself.
Yes, if the vendor stores, transmits, or can access ePHI, which any cloud backup provider does. Get the BAA before data flows, keep a copy in your compliance file, and confirm the vendor's own security practices, since you remain responsible for choosing them.
Automated verification should run daily. A documented restore of real data, such as a specific patient chart or a whole server, should happen at least quarterly. A full disaster recovery exercise, restoring the EMR to a usable state, should be done at least once a year with the results written down.
No. Retention policies and litigation hold prevent permanent deletion inside the platform, but they are not an independent, restorable copy. If an attacker with admin credentials deletes data or a policy is misconfigured, retention does not help. Practices need a separate third-party backup for email and cloud files.
Designing, running, and testing backup and disaster recovery for medical practices is core to what we do across DFW and Houston, and it ties directly into cybersecurity and the contingency plan documentation your regulatory compliance file needs. Whether your current backup would actually restore is usually the first thing we test.
Ready for a straight answer about your IT? Call (972) 776-6366 or contact us.